Re: WebClient-Core port to Pharo 1.1 final

>>> We want a library where people can participate. Now Pharoers will decide,
>>> I think that we do not have problem
>>> with sharing on WebClient. I can understand that people do not like that
>>> they cannot improve an infrastructure
>>> that they will rely upon. We do not want string to number conversion, and
>>> rely on squeakToUtf.
>>
>> I think Andreas solved these issues with the WebClient-Pharo package, but I
>> may be wrong.
>
> What WebClient-Pharo does is to patch (and break) Pharo in the most
> absurd ways to make it ill-behaved like Squeak. For example, check out
> the implementation of String>>#,.

>
>> Well, we are about to use it for Seaside. It scales a lot better than Kom.
>> Cog can't really speed up Kom (based on our benchmarks done with JMeter)*,
>> probably because of the heavy use of notifications (DynamicBindings), but it
>> can boost WebClient significantly.
>
> Kom is not ideal, we all know that (thanks for sharing the
> benchmarks). However, the current licensing situation of WebClient
> makes it totally useless for me and presumably many other people.
> Luckily there are many other options.
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi  wrote ----
>
>> I don't like the "magical" #asString, but you should discuss it with
>> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in
>> the WebClient-Pharo package (and in Squeak), and I think it's better than
>> nil.
>
> I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
>
> The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.

>
> On 30 Aug 2010, at 15:35, jaayer wrote:
>
>> ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi  wrote ----
>>
>>> I don't like the "magical" #asString, but you should discuss it with
>>> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in
>>> the WebClient-Pharo package (and in Squeak), and I think it's better than
>>> nil.
>>
>> I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
>>
>> The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
>
> heu... I evaluated the following in a pharo1.1-dev and 1.2-core:
>
> (#(foo) ifEmpty:[#bar]) -> returns #(foo)
> (#() ifNotEmpty:[#bar]) -> returns #()
>
> This seems to do what you propose?
> Johan
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
> ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi  wrote ----
>
>> I don't like the "magical" #asString, but you should discuss it with
>> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in
>> the WebClient-Pharo package (and in Squeak), and I think it's better than
>> nil.
>
> I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
>
> The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>> ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi  wrote ----
>>>
>>>> I don't like the "magical" #asString, but you should discuss it with
>>>> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in
>>>> the WebClient-Pharo package (and in Squeak), and I think it's better than
>>>> nil.
>>>
>>> I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
>>>
>>> The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
>>
>> heu... I evaluated the following in a pharo1.1-dev and 1.2-core:
>>
>> (#(foo) ifEmpty:[#bar]) -> returns #(foo)
>> (#() ifNotEmpty:[#bar]) -> returns #()
>>
>> This seems to do what you propose?
>> Johan
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> Yes.
> Levente is right, I read the code of Andreas' wrong.
> Pharo 1.1/1.2 does this, so the override is for 1.0, where #ifEmpty: returns nil .
>
> Cheers,
> Henry
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>>> ---- On Mon, 30 Aug 2010 05:57:47 -0700 Levente Uzonyi  wrote ----
>>>>
>>>>> I don't like the "magical" #asString, but you should discuss it with
>>>>> Andreas. Collection >> #ifEmpty: doesn't return nil, but the collection in
>>>>> the WebClient-Pharo package (and in Squeak), and I think it's better than
>>>>> nil.
>>>>
>>>> I opened a ticked on this a few weeks back: http://code.google.com/p/pharo/issues/detail?id=2794
>>>>
>>>> The ifEmpty:/ifNotEmpty: behavior of Squeak is demonstrably better and should be adopted.
>>>
>>> heu... I evaluated the following in a pharo1.1-dev and 1.2-core:
>>>
>>> (#(foo) ifEmpty:[#bar]) -> returns #(foo)
>>> (#() ifNotEmpty:[#bar]) -> returns #()
>>>
>>> This seems to do what you propose?
>>> Johan
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> Yes.
>> Levente is right, I read the code of Andreas' wrong.
>> Pharo 1.1/1.2 does this, so the override is for 1.0, where #ifEmpty: returns nil .
>>
>> Cheers,
>> Henry
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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.

> My 2 cents about WebClient.
>
> - it should be an (un)loadable external package, and i am fully agree
> with Andreas on this point.
> It is tempting to integrate it into image, do some tweaks here and
> there and then ship it within a monolitic image.
> But then, from maintainer's point of view, it is quite hard to keep
> developing it and improving, since it may break
> things in random places over multiple forks etc etc, and then who will
> be accused in such breakage? - a maintainer.

>
> It is good to have a person, who personally responsible for
> maintaining a package, or even if by a group of people,
> it should use a separate repository for developing it.
>
> Otherwise, if you integrate it into image, by doing that you:
>  - losing a maintainer , who willingly contributing to this project
>  - in same turn, must take own responsibility for maintaining it,
> which means extra work for you, whenever you having
>   problems with it.

> El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribió:
>> My 2 cents about WebClient.
>>
>> - it should be an (un)loadable external package, and i am fully agree
>> with Andreas on this point.
>> It is tempting to integrate it into image, do some tweaks here and
>> there and then ship it within a monolitic image.
>> But then, from maintainer's point of view, it is quite hard to keep
>> developing it and improving, since it may break
>> things in random places over multiple forks etc etc, and then who will
>> be accused in such breakage? - a maintainer.
>
> Of course not, we, the ones using it as part of our core image are the
> ones responsible of the correct functioning in our image. It would be
> childish to run crying to Andreas that it break our image because we are
> taking the decision of integrating it in the core image. Now, this of
> course doesn't apply to core functionality or that breaks the contract
> the code offers to its clients. That type of API changes will be
> discussed with Andreas and if no solution found, the pharo developers
> will found a workaround so that is remains working correctly.
>
> What I don't understand is why such imposition to the way of use the
> software. If it decided to have an open source license he can't restrict
> the uses of the software. This is a real open source implications.
>
>
>>
>> It is good to have a person, who personally responsible for
>> maintaining a package, or even if by a group of people,
>> it should use a separate repository for developing it.
>>
>> Otherwise, if you integrate it into image, by doing that you:
>>  - losing a maintainer , who willingly contributing to this project
>>  - in same turn, must take own responsibility for maintaining it,
>> which means extra work for you, whenever you having
>>   problems with it.
>
> Of course, that is the point. Nobody expects otherwise.
>

>>
>> We should learn how to integrate things without intimately tying
>> everything with a single bloated image.
>
> Isn't as we are integrating moose or seaside in the core image is a
> basic infrastructure thing, a http client, that every modern language in
> the current times includes in their core libraries (java, ruby, lisp).
>
>> And WebClient could be right thing for learning that (Seaside too ;).
>>
>
>
> --
> Miguel Cobá
> http://miguel.leugim.com.mx
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>>>> 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
>
> <TextConverting.zip>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
> 2010/8/30 Miguel Enrique Cobá Martínez <[hidden email]>
>>
>> El lun, 30-08-2010 a las 18:25 +0300, Igor Stasenko escribió:
>> > My 2 cents about WebClient.
>> >
>> > - it should be an (un)loadable external package, and i am fully agree
>> > with Andreas on this point.
>> > It is tempting to integrate it into image, do some tweaks here and
>> > there and then ship it within a monolitic image.
>> > But then, from maintainer's point of view, it is quite hard to keep
>> > developing it and improving, since it may break
>> > things in random places over multiple forks etc etc, and then who will
>> > be accused in such breakage? - a maintainer.
>>
>> Of course not, we, the ones using it as part of our core image are the
>> ones responsible of the correct functioning in our image. It would be
>> childish to run crying to Andreas that it break our image because we are
>> taking the decision of integrating it in the core image. Now, this of
>> course doesn't apply to core functionality or that breaks the contract
>> the code offers to its clients. That type of API changes will be
>> discussed with Andreas and if no solution found, the pharo developers
>> will found a workaround so that is remains working correctly.
>>
>
> Agree with Miguel. It is the smae situation as Gofer.  Lukas is the main
> developer of Gofer but we (pharo developers) maintain it. When a message is
> removed or renamed for example, we take care about its senders, for all
> packages, included Gofer. And we are the responsible, not Lukas.
>
>>
>> What I don't understand is why such imposition to the way of use the
>> software. If it decided to have an open source license he can't restrict
>> the uses of the software. This is a real open source implications.
>>
>>
>> >
>> > It is good to have a person, who personally responsible for
>> > maintaining a package, or even if by a group of people,
>> > it should use a separate repository for developing it.
>> >
>> > Otherwise, if you integrate it into image, by doing that you:
>> >  - losing a maintainer , who willingly contributing to this project
>> >  - in same turn, must take own responsibility for maintaining it,
>> > which means extra work for you, whenever you having
>> >   problems with it.
>>
>> Of course, that is the point. Nobody expects otherwise.
>>
>> >
>> > We should learn how to integrate things without intimately tying
>> > everything with a single bloated image.
>>
>> Isn't as we are integrating moose or seaside in the core image is a
>> basic infrastructure thing, a http client, that every modern language in
>> the current times includes in their core libraries (java, ruby, lisp).
>>
>> > And WebClient could be right thing for learning that (Seaside too ;).
>> >
>>
>>
>> --
>> Miguel Cobá
>> http://miguel.leugim.com.mx
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Hi Pharoers,
> I'm happy to read mail from Torsten, Igor and Miguel, thank you guys
> that's constructive.
> Andreas expressed his point very well, and i don't think it is
> hostile, maybe a bit sarcastic or disenchanted, but overall he keeps
> the door opened.
> The first thing to do is to cool down, relax and think.
> The second thing to do is engaging discussion with Andreas.
>
> Of course, the license is of prime importance, not having a license is
> a showstopper.
> If license is too restrictive then Andreas will probably fail to reach
> his goals...
> There will be de facto full rewrite rather than forks, but the net
> result will be the same: failure to share packages/libraries.

> After the license problem, there is the technical compatibility problem.
> Discussions about cross fork compatibility, compatibility layers or
> libraries (a la GREASE) will have to occur anyway, be it about Andreas
> library or from any other author. So you'll have to take time to
> discuss. Don't consider this as lost time. These discussions are
> considered necessary when they regularly happens in Pharo mailing
> list, aren't they ? It shouldn't be that hard to convince Andreas to
> change things like and:and:and:. For squeakToUtf8, I don't know, maybe
> provide some automated rewrite rules, and produce an automated Pharo
> version ?