Thanks
http://code.google.com/p/pharo/issues/detail?id=2893
Network will be soon in our radar. full of broken code
Stef
On Sep 1, 2010, at 6:16 AM, Andreas Raab wrote:
> Hi Sven -
>
> I had a quick look at the failing tests on Pharo and they seem mostly the
> result of bugs in Pharo's Network package. First, MimeDocument>>url needs to
> return an instance of Url not a string (check the senders; all users of it
> expect it to be a Url not a string) so if you change that to return a url
> it'll take care of the pathForFile issue.
>
> The failure of testMultiPartPost2 is a combination of two bugs in HTTPSocket.
> First, there's a typo in getResponseUpTo: at the end (this needs to be
> #copyFrom:to: (the "to" is missing the colon). Second, there is
> httpPostMultiPart: which adds an erroneous CrLf at the end of a persistent
> HTTP/1.1 connection. That causes an interesting series of things to go wrong
> (which I'm partly still investigating) but the easy solution is to insert a
> "Connection: close" header.
>
> Fixes attached. These are of course also broken in Pharo 1.0 and 1.1.
>
> Cheers,
> - Andreas
>
> On 8/30/2010 2:17 AM, Sven Van Caekenberghe wrote:
>> Hi Andreas,
>>
>> Thank you for clarifying your position and for pointing out the lack of a
>> proper license for WebClient code.
>>
>> I and other people in the Pharo community made a mistake and we're sorry. We
>> will be more careful in the future.
>>
>> But to our defense, as others pointed out, you're communications gave the
>> impression that this was true open source, compatible with the standard
>> Squeak one in spirit.
>>
>> Futhermore, and this to your credit as well, you yourself wrote the
>> WebClient-Pharo package, giving the impression that you valued that port. It
>> also proves that you did the actual effort. Thanks you!
>>
>> And indeed, you did incorporate some changes, so the intention was certainly
>> there.
>>
>> Now, I would not say that we already actually forked the code. We just tried
>> to port it. The process of following your progress proved difficult (you
>> probably made a diff between your and our latest versions), precisely
>> because of some of these little things like #asString, #utf8Encoding,
>> #and:and:and:and:, but also some deeper ones like #pathForFile that kept
>> coming back.
>>
>> You have every right to refuse to follow the Pharo Smalltalk spirit or
>> style. I respect that, and the Pharo community as a whole should too.
>>
>> But your refusal to do so and the lack of a license give us no alternative
>> than to look for other solutions.
>>
>> I wasn't there when the discussion that let to the birth of Pharo took
>> place. But it is clear that the Smalltalk community is too small to not work
>> together.
>>
>> The Smalltalk-80 inheritance and the enormeous contributions of the Squeak
>> community over the years should be respected by all. At the same time you
>> cannot ignore the positive effect that Pharo had since then. For me and many
>> others, Pharo definitively has its place, along many other viable Smalltalk
>> implementations.
>>
>> Regards,
>>
>> Sven
>>
>> On 30 Aug 2010, at 00:00, Andreas Raab wrote:
>>
>>> Hi Sven,
>>>
>>> [cc: pharo list since I think there are some larger issues to discuss]
>>>
>>> First of all thank you for your continued interest in WebClient. It is nice
>>> to see that people like to use it. However, I'm more than a bit surprised
>>> about what you are saying below about having WebClient in Pharo 1.2.
>>> Honestly, I was dumbfounded when I went to read some of the discussions on
>>> the Pharo list.
>>>
>>> May I ask what the due diligence process is for including packages in
>>> Pharo? I would have expected that the process includes 1) checking the
>>> project page on SS for the license and 2) sending the author a courtesy
>>> note along the lines of "hey we want to include your code, are you okay
>>> with that?" (in particular if the author of the package isn't on the Pharo
>>> list and consequently has no clue about what you're doing).
>>>
>>> 1. Regarding WebClient's license, please have a look at any of the
>>> following repositories, all of which are under MIT:
>>>
>>> http://www.squeaksource.com/Balloon3D.html
>>> http://www.squeaksource.com/CroquetGL.html
>>> http://www.squeaksource.com/ToolBuilder.html
>>> http://www.squeaksource.com/TweakCore.html
>>> ... etc ...
>>>
>>> As you can see, when I mean to put code under the MIT license, I try to
>>> state that by including a copy of the license on the front page of the
>>> repository as well as setting the license field. Contrary to, for example,
>>> the following repositories:
>>>
>>> http://www.squeaksource.com/ar.html
>>> http://www.squeaksource.com/SqueakSSL.html
>>> http://www.squeaksource.com/WebClient.html
>>>
>>> which are not (or not yet) under MIT. Obviously, I'm trying to be as clear
>>> as possible on these matters, which is why I was pointing out that your
>>> repository incorrectly claims that the version of WebClient in it is
>>> LGPLv2. I'm surprised (and shocked) that apparently nobody in Pharo even
>>> tries to find out what the license status for WebClient is.
>>>
>>> 2. Regarding my intentions / position you'll have to keep in mind that I
>>> don't read the Pharo list. I tried to follow it in the past only to be
>>> faced with several vicious attacks against Squeak and myself and as a
>>> consequence I stopped reading it. Consequently, this is the first time
>>> anyone has ever mentioned the inclusion of WebClient in Pharo to me.
>>>
>>> In short, my position is that we need more shared libraries, not more
>>> forks. You will probably see the irony that I specifically didn't set a
>>> license on WebClient to prevent such forks without any prior discussion
>>> (under the hopelessly naive assumption that there would be some sort of due
>>> diligence process) only to find out that you've forked WebClient already.
>>> How very ironic indeed.
>>>
>>> Because of my position above, I think WebClient should be an external
>>> package, loaded for example via Metacello configuration. In fact, that's
>>> exactly why I provided a Metacello configuration to begin with. Can someone
>>> perhaps explain where the urge to include (and consequently fork) WebClient
>>> comes from? WebClient is a perfectly good external package and for the time
>>> being I prefer it should stay that way. If you want to replace HTTPSocket,
>>> then have a look at Squeak 4.2 which contains a very simple HTTPSocket
>>> implementation that has hooks so that WebClient will be used if it's loaded.
>>>
>>> Regarding fixes for Pharo, as far as I know the only changes that I haven't
>>> included was a bunch of #asString sprinkled all over the places, and the
>>> abominations of replacing #squeakToUtf8 and #utf8ToSqueak with
>>> "convert[From|To]WithConverter: UTF8TextConverter new". On both of these
>>> issues I feel very strongly; I will not make the code substantially worse
>>> only to deal with shortcomings of Pharo. So if you cannot come to a
>>> reasonable resolution for these, you'll need the extension methods. Outside
>>> of that, I believe that not only have I integrated all the fixes that have
>>> been sent to me, I have also added several patches to WebClient-Pharo that
>>> provide important fixes for (in Pharo broken) network operations without
>>> which WebClient would not work in any released Pharo versions.
>>>
>>> Summary:
>>> * I'm surprised and I'm shocked to see that there is apparently no due
>>> diligence regarding new packages in Pharo. I find this in particular
>>> shocking giving the wild claims on the Pharo web site that "From the
>>> beginning of Pharo we have maintained a strict rule that every contributor
>>> has to sign our license agreement." I haven't. (and geez, when did Michael
>>> got dropped from the Pharo board?)
>>>
>>> * I don't want WebClient to be included in Pharo since this means you will
>>> be producing a Pharo-only fork of WebClient which is counter-productive
>>> from my perspective. I want WebClient to remain a shared loadable package
>>> with a canonical source repository available to all forks of Squeak,
>>> including Pharo.
>>>
>>> * I have, and will continue to do so, integrate fixes for Pharo as long as
>>> I consider them reasonable. If there is interest, I can also provide an
>>> updated Metacello configuration; although that really just boils down to
>>> updating it to the latest package versions.
>>>
>>> Cheers,
>>> - Andreas
>>
>>
> <NetworkFixes-ar.1.cs>_______________________________________________
> 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
