On Aug 30, 2010, at 2:57 47PM, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Henrik Johansen wrote:
On Aug 30, 2010, at 1:06 10PM, Levente Uzonyi wrote:
On Mon, 30 Aug 2010, Stéphane Ducasse wrote:
I suggest that the people that want and know, group together and build an open-source one.
Why do you have to have your "own" library?
Did I say "pharo library"? reread carefully I said an "open-source one".
What I get from Andreas' words is that he's willing to make it open source if it won't be forked.
So, definitely not MIT then.
Why? Because the MIT license explicitly sets no limit on the users right to modify, publish and distribute the software. A condition that it can not be published/used in a modified (forked) form would exclude using MIT.
I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well?
I don't think so. Squeak releases won't come with WebClient loaded, Andreas mentioned it in his mail.
In a reply to the original announcement, Andreas also said: "On 5/4/2010 11:11 PM, Casey Ransberger wrote:
Are you intent on replacing HTTPSocket in the long run? I have an RPC-ish thing that uses it, so I'd like to be clear on whether I can expect it to be around for the next release.
In the long run: Yes. In the next release: No. And "replacing" can mean that the public interface in HTTPSocket remains. That's what the WebClient-HTTP package does. It patches HTTPSocket to use WebClient while preserving the identical external interface. " which to me implied eventual integration in Squeak core (as did the removal of HttpSocket functionality based on it being offered by WebClient)
If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes.
In Squeak these methods avoid the creation of the TextConverter object if the receiver is a ByteString, which is usually the case.
Levente
Yes, the major performance differences come from not creating copies if the strings are ascii, and #convertTo/FromEncoding: doing subclass lookup to find the converter though. AFAICT, it's maximally about 2 times faster in the best case (small, pure ascii strings) where it avoids both copies and a lookup compared to a convertTo/FromEncoding modified to do lookup in a dictionary rather than iterating subclasses. For the WebSocket use-cases though, I really don't see how the performance matters all that much. You convert roughly 200k 4KB ascii strings per second either way, and with a single non-ascii char, the difference falls to near negligible. "MediumDoc is a pure ascii ByteString of size 4096" [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 MediumDoc at: 2048 put: $Ã¥. [1 to: 100000 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 1451 1438 [1 to: 100000 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 1463 1470 Cheers, Henry