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?
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.
We do not want to be in the situation that somebody can change the license
under our feet.
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.
If you call overriding String #, (to accept any object responding to asString without
raising errors) and Collection #ifEmpty: (to return nil instead of the collection
ifNotEmpty) "solving the issues" in Pharo, then yeah, sure.
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.
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
Personally, I'd call it forcing Squeakisms on anyone wanting to use WebClient,
and potentially breaking any number of other packages.
The rest I have no problems with, most are fixes/convenience methods which are
already in, or should be introduced before Pharo 1.2 (for exampe the
SocketStream fixes )
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
