Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Don't confuse open-source software with free software: http://www.gnu.org/philosophy/free-software-for-freedom.html 2010/8/31 Miguel Enrique Cobá Martínez miguel.c...@gmail.com: El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. From wikipedia: Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software. There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. See above. You could fork it, but that wouldn't be open source anymore. You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period. Levente Cheers Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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, MimeDocumenturl 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
El mié, 01-09-2010 a las 15:44 +0900, Serge Stinckwich escribió: Don't confuse open-source software with free software: http://www.gnu.org/philosophy/free-software-for-freedom.html I think that this has already gone off-topic. The original argument was that Andreas wanted to open source it (MIT likely) and at the same time prohibiting forking of the codebase. My point was that if it was open source or free software then the forking was a granted right. If he wanted to avoid it then he couldn't claim is free software or open source. With MIT you can fork (of course) but also with GPL (like the emacs/xemacs fork). Let not bring this thread in a free software vs open source war. Cheers 2010/8/31 Miguel Enrique Cobá Martínez miguel.c...@gmail.com: El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. From wikipedia: Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software. There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. See above. You could fork it, but that wouldn't be open source anymore. You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period. Levente Cheers Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/9/1 Miguel Enrique Cobá Martínez miguel.c...@gmail.com El mié, 01-09-2010 a las 15:44 +0900, Serge Stinckwich escribió: Don't confuse open-source software with free software: http://www.gnu.org/philosophy/free-software-for-freedom.html I think that this has already gone off-topic. The original argument was that Andreas wanted to open source it (MIT likely) and at the same time prohibiting forking of the codebase. My point was that if it was open source or free software then the forking was a granted right. If he wanted to avoid it then he couldn't claim is free software or open source. With MIT you can fork (of course) but also with GPL (like the emacs/xemacs fork). Let not bring this thread in a free software vs open source war. +1 Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ Cheers 2010/8/31 Miguel Enrique Cobá Martínez miguel.c...@gmail.com: El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. From wikipedia: Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software. There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. See above. You could fork it, but that wouldn't be open source anymore. You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period. Levente Cheers Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Andreas, Thanks a lot for taking the time to look into these problems and for the patches. Shouldn't we try to capture these problems with unit tests running across Squeak and its derivatives ? What would be the procedure to contribute to these tests ? Sven On 01 Sep 2010, at 06:16, 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, MimeDocumenturl 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Schwab,Wilhelm K bsch...@anest.ufl.edu writes: Levente, I stand by the analogy of GPL's history and the more emotional undertones of the current discussion. Dismissing it won't make it go away. IMHO you are fully right. The fact still is if something is OS it forkable. Maye under certain conditions but it surely is forkable. I avoid GPL software as much as I can (but well I'm running Debian Linux) so there's not escape really. However I'm just using it... Makes life easier ;-) Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
thanks added to http://code.google.com/p/pharo/issues/detail?id=2885 Stef On Aug 31, 2010, at 12:22 AM, Levente Uzonyi wrote: In Squeak(CogVM): 7-bit ByteString mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. === #(344 345 344 347 344) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(404 373 375 374 374) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1443 1440 1438 1443 1445) 7-bit ByteString with a single 8-bit character mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. mediumDoc at: 2048 put: (Character value: 128). (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. === #(1262 1246 1249 1250 1249). (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(1261 1256 1264 1260 1258) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(2591 2567 2538 2543 2582) Not neglible (~0.5 speed) 8-bit ByteStrings (only 1000 conversion/test) mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 256 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. === #(627 618 618 622 618) (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(648 621 620 621 622) (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(676 653 650 658 648) WideStrings mediumDoc := String new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: (122) atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. === #(632 635 633 632 633) (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(693 625 625 626 625) (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(644 637 640 640 638) So, for 7-bit ByteStrings (optionally with few 8-bit characters), it does make a difference to use #squeakToUtf8, for 8-bit ByteStrings and WideStrings it doesn't really matter. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Hi - Thanks everyone for the reasoned and civil responses. It is good to see that we can have a disagreement without getting overly personal. Unfortunately, it seems that I'm effectively offered a no-win alternative here; I do not see how any of the discussed alternatives would help me achieve my goals. I will have to think about where to take things from here. If anyone has ideas, please let me know. Cheers, - Andreas On 8/30/2010 12:57 PM, Nicolas Cellier wrote: 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. That's why I personnally don't find Andreas defensive position a good strategy. Neither the attitude in response... It's like you're happy to throw his work away at first occasion without even trying to negociate. Bad vibrations. Before you engage in this (war)path, please, please, discuss. And remind this saying il ne faut pas confondre vitesse et précipitation. If no agreement is found then, ok, you'll get a license to carry on. 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 ? Please, discuss, argue, explain why you consider certain constructions as bad style. Propose alternatives (be constructive - remember coopetition ?). I consider being unable to explain one's own choice as a weakness. Don't be weak. Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Nicolas 2010/8/30 Mariano Martinez Peckmarianop...@gmail.com: 2010/8/30 Miguel Enrique Cobá Martínezmiguel.c...@gmail.com 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
so now we understand why Pharo design is crap :) Sorry I could resist It would be nice if we were a bit more adults. What is strange is that some people catalyze communication problems (me included) but we should live with that. I added your bench to the issue too. Stef On Aug 31, 2010, at 12:34 AM, Levente Uzonyi wrote: And another with SmallDoc: smallDoc := ByteString new: 20 streamContents: [ :stream | 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc squeakToUtf8 ] ] timeToRun ]. === #(15 15 15 15 15) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(34 34 34 35 32) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1256 1258 1259 1260 1260) smallDoc := ByteString new: 20 streamContents: [ :stream | 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. smallDoc at: 10 put: (Character value: 129). (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc squeakToUtf8 ] ] timeToRun ]. === #(115 112 112 113 112) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(157 125 124 126 125) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1416 1419 1419 1429 1428) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
don;t worry levente Nicolas was sensitive to the fact that you laugh because you consider that our process is close and that I have all the powers, which is false. We proposed in the past to Nicolas to help integrate changes but this is too boring in pharo so I do the dirty work and should work on making something simpler so that other can join if they want. BTW nicolas now we have menus and a lot more the rest (even automatic password settings) so a simple change is integrated in 2 min, merge and verification of the load in another image. so this is not bad. Stef On Aug 31, 2010, at 12:49 AM, Levente Uzonyi wrote: On Mon, 30 Aug 2010, Nicolas Cellier wrote: Hi Pharoers, snip Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Uh, what remark? Nicolas snip ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
snip Yeah, that's why I added the 20 4KB docs / sec number. I really doubt the conversion will be a significant part of the processing time if what you send out is so small you are able to convert 800k messages per second... It depends on the machine/load/etc. I feel like we already had this discussion over the cull: implementation, and I doubt either of us is going to change their mind, so let's stop here :) but cull: is in squeak now I think :) I did not look carefully See the code I attached last mail, switching to convertToEncoding: 'utf8' sort of implied implementing something like that, which gives it nearly the same speed as convertToWithConverter: UTF8TextConverter new in your examples. Sorry, I didn't see that. It looks cool, but I still wouldn't use #convertToEncoding: in my code, because there's a similar looking method (#converToWithConverter:) with better performance :). Sure, though I find it quite ugly, I wouldn't vehemently oppose using it either, but the issue here was finding something Andreas would accept :) But it's definitely better than the current version, though if a converter is added/changed/removed, the dictionary has to be updated manually. Levente Yeah, the code was merely a proof of concept to show off that you could get acceptable (for some :P) performance using it, as a middleground between squeakToUtf8 and convertToWithConverter in terseness. 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On 8/30/2010 1:40 AM, Johan Brichau wrote: I am not a lawyer but as far as I understand this topic, no license means nobody can use the code at all, which contradicts the fact of having it in a public repository (and you being perfectly happy of people using it). Can you please clarify the license situation of those projects? The license situation is that the code that's there has not been made available with a specific license yet. I use that as a vehicle to allow people to check things out, to try stuff and to experiment with it while I'm developing the code and am not willing to give up control. If you feel you do need a license during that period (which is perfectly reasonable) you can always contact and ask me and I'll be more than happy to grant you a non-transferable license that restricts source redistribution but is otherwise completely free for your use (commercial or otherwise). The point isn't to keep people from trying things out, the point is to bring development to a point where I'm happy to release it in the chosen form to the general public. Cheers, - Andreas On 30 Aug 2010, at 00:00, Andreas Raab wrote: 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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On 31.08.2010 08:47, Stéphane Ducasse wrote: snip Yeah, that's why I added the 20 4KB docs / sec number. I really doubt the conversion will be a significant part of the processing time if what you send out is so small you are able to convert 800k messages per second... It depends on the machine/load/etc. I feel like we already had this discussion over the cull: implementation, and I doubt either of us is going to change their mind, so let's stop here :) but cull: is in squeak now I think :) I did not look carefully Yes, the discussion wasn't over its usefulness. Like now, it was whether the degree of optimization Levente presented was useful in any real scenarios :) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Originally I thought to shut up but today is the last days of summer holidays and I'm a positive thinking so let us try to help My suggestions: - put MIT now - accept other submissions even open the repositories to people that are cool (lukas, philippe, sven) - trust others! - have a look at HCHTTPClient and may be merge, migrate, - let pharo uses in it the image, we are not that dumb and with the merging capability and rss feed somebody can merge back really fast. Stef On Aug 31, 2010, at 8:38 AM, Andreas Raab wrote: Hi - Thanks everyone for the reasoned and civil responses. It is good to see that we can have a disagreement without getting overly personal. Unfortunately, it seems that I'm effectively offered a no-win alternative here; I do not see how any of the discussed alternatives would help me achieve my goals. I will have to think about where to take things from here. If anyone has ideas, please let me know. Cheers, - Andreas ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/8/31 Levente Uzonyi le...@elte.hu: On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period. If you agree with OSI. Right. People always get into this argument. OSI has a definition of Open Source that is based on a moral position of having certain freedoms with the code. Legally, however, there is no such definition. When you write code, you (or your employer) own the code and you (or your employer) can release it under more or less any license—and with any restrictions—you desire. If I wanted, I could release code with the restriction that you can only use it on Wednesday! The right to create derivative works—obviously a significant component of forking—is restricted by copyright law unless the creator explicitly grants that right to you. So you're perfectly free to say that WebClient is not Open Source if you wish; but you don't obtain specific rights just because the source is open. Your rights are entirely determined by your license with the creator(s). That's all I'll contribute to this discussion for the moment. We're working with intellectual property lawyers to prepare our ESUG talk on open source licensing; hopefully we'll be able to touch on some of this then and have some useful resources for the community as an output. Julian ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
That's all I'll contribute to this discussion for the moment. We're working with intellectual property lawyers to prepare our ESUG talk on open source licensing; hopefully we'll be able to touch on some of this then and have some useful resources for the community as an output. Julian please no public advertisement for this cool conference on this mailing-list, we are serious people working and not dreaming about the charm of Barcelona. :D ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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, MimeDocumenturl 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Hi andreas 1- We talked a lot about Webclient used in the Pharo mailing-list and we were stupid to think that you read it. Luckily you did it at last. 2- I'm also surprised that nobody checked the license (me the first). Shit happens even with the best attitude. We are paying attention to contributor and we learned something today. 3- Philippe contacted you with fixes several times and got no reply, sven too so people thought that you do not want to talk to them. Apparently not so this is good. 4- We want to have a good web library in Pharo, so this will not webclient. I do not believe that this is good to build any software on libraries that have an unclear license. At least I would not do it just to avoid to get trap in it. 5- We will remove (by today) WebClient from Pharo. 6- Pharoers will have to decide and probably to build an open one under MIT. 6- Some people do not like that they cannot improve the code they see and use daily. 7- This is your right to criticize the code quality and design of Pharo, there is no problem with that. We have another point of view after the years we spent. Now they may be some little glitches and if you have precise feedback we are open to hear them. We are working working working and ... working on it and we are improving everyday -- may be too slowly. Stef 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Sven and philippe I was wondering what was the license of your submissions to webClient. Because this will be also a problem. Either you totally give it to andreas and he can do what he wants with it, or you retain the right on the code and andreas has to decide what he will do with it. Since you can change the license of your code I imagine that andreas will not include any code if the code is not given to him. Funny situation. I think that it is even more confusing than with the old Squeak-L. Stef On Aug 30, 2010, at 12:00 AM, 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.
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
I fully agree with Stef. I don't remember why I assumed the license was MIT, maybe because on Andreas' blog it says: we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1. Isn't the missing license an issue for Squeak? Anyway, obviously its a no-go not only for Pharo but also for companies (like us at Cmsbox, who considered using WebClient in the future). Cheers, Adrian Zitat von Stéphane Ducasse stephane.duca...@inria.fr: Hi andreas 1- We talked a lot about Webclient used in the Pharo mailing-list and we were stupid to think that you read it. Luckily you did it at last. 2- I'm also surprised that nobody checked the license (me the first). Shit happens even with the best attitude. We are paying attention to contributor and we learned something today. 3- Philippe contacted you with fixes several times and got no reply, sven too so people thought that you do not want to talk to them. Apparently not so this is good. 4- We want to have a good web library in Pharo, so this will not webclient. I do not believe that this is good to build any software on libraries that have an unclear license. At least I would not do it just to avoid to get trap in it. 5- We will remove (by today) WebClient from Pharo. 6- Pharoers will have to decide and probably to build an open one under MIT. 6- Some people do not like that they cannot improve the code they see and use daily. 7- This is your right to criticize the code quality and design of Pharo, there is no problem with that. We have another point of view after the years we spent. Now they may be some little glitches and if you have precise feedback we are open to hear them. We are working working working and ... working on it and we are improving everyday -- may be too slowly. Stef 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Hi pharoers What do you think? I think that we should not have any software parts whose license is not set clearly in Pharo. So I will remove WebClient from Pharo. I suggest that the people that want and know, group together and build an open-source one. Stef On Aug 30, 2010, at 12:00 AM, 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
[Pharo-project] WebClient-Core port to Pharo 1.1 final
I agree with Andreas that the process for including packages in Pharo is not transparent (at least not me). Dont know the process for Squeak either - but at least we all should take care to keep the whole platform and forks open. Maybe the license should be a required field in Squeaksource for any new project. Havent followed the whole thread - but I still wonder what the reason for Andreas is to not release Webclient as MIT? Especially since I think it could be a nice addition to the standard images (Squeak, Pharo or whatever) ... Bye T. -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://portal.gmx.net/de/go/dsl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
A final point: I can understand that andreas does not want to get fork. I understand that he can think that we are stealing code. I think that this is fair to think that. Now as miguel mentioned about SPDF, the solution is in the process: one way to avoid fork is to be open to other changes and to get a real review process and some compromise. We should have contacted him publicly but we still have some communication problems :) This is a long period of time since we did not said any vicious, I personally prefer positive energy and I'm ranting clean. Pharo is my red pil. :) Now I think that not putting license is not a solution that can scale but this is his choice. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, Aug 30, 2010 at 10:12 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi pharoers What do you think? I think that we should not have any software parts whose license is not set clearly in Pharo. So I will remove WebClient from Pharo. It can still be maintained as an external package and it seems it's Andreas intent. Anyway, WebClient must have a licence. No licence means nobody can use it (even Squeak). So I would like to know the licence before any decision. PS: I don't understand the '(code) forks are evil' statement, I think it encourages project forks and closes contribution. This currently happens it seems. Reminds me the squeak-vm on github thread . Laurent I suggest that the people that want and know, group together and build an open-source one. Stef On Aug 30, 2010, at 12:00 AM, 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Adrian Same for squeakSSL. :) Stef On Aug 30, 2010, at 10:03 AM, a...@netstyle.ch wrote: I fully agree with Stef. I don't remember why I assumed the license was MIT, maybe because on Andreas' blog it says: we now have what I think is a pretty decent HTTP server and client implementation for Squeak 4.1. Isn't the missing license an issue for Squeak? Anyway, obviously its a no-go not only for Pharo but also for companies (like us at Cmsbox, who considered using WebClient in the future). Cheers, Adrian Zitat von Stéphane Ducasse stephane.duca...@inria.fr: Hi andreas 1- We talked a lot about Webclient used in the Pharo mailing-list and we were stupid to think that you read it. Luckily you did it at last. 2- I'm also surprised that nobody checked the license (me the first). Shit happens even with the best attitude. We are paying attention to contributor and we learned something today. 3- Philippe contacted you with fixes several times and got no reply, sven too so people thought that you do not want to talk to them. Apparently not so this is good. 4- We want to have a good web library in Pharo, so this will not webclient. I do not believe that this is good to build any software on libraries that have an unclear license. At least I would not do it just to avoid to get trap in it. 5- We will remove (by today) WebClient from Pharo. 6- Pharoers will have to decide and probably to build an open one under MIT. 6- Some people do not like that they cannot improve the code they see and use daily. 7- This is your right to criticize the code quality and design of Pharo, there is no problem with that. We have another point of view after the years we spent. Now they may be some little glitches and if you have precise feedback we are open to hear them. We are working working working and ... working on it and we are improving everyday -- may be too slowly. Stef 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Hi Andreas, I am not a lawyer but as far as I understand this topic, no license means nobody can use the code at all, which contradicts the fact of having it in a public repository (and you being perfectly happy of people using it). Can you please clarify the license situation of those projects? Best regards, Johan On 30 Aug 2010, at 00:00, Andreas Raab wrote: 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. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Aug 30, 2010, at 10:27 AM, Torsten Bergmann wrote: I agree with Andreas that the process for including packages in Pharo is not transparent (at least not me). read the open and transparent discussions that happened over the past months in this mailing-list: check for webClient in the title :) For pharo: this is really simple - we discuss in the mailing-list - reach a consensus - act. Tell me once you will have read the mails if this is not what we did and how we could improve them. I would like to have the same process than python but we are too small for that right now. Dont know the process for Squeak either - but at least we all should take care to keep the whole platform and forks open. Maybe the license should be a required field in Squeaksource for any new project. Havent followed the whole thread - but I still wonder what the reason for Andreas is to not release Webclient as MIT? Especially since I think it could be a nice addition to the standard images (Squeak, Pharo or whatever) ... Bye T. -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 ¿/mtl.!* http://portal.gmx.net/de/go/dsl ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
ESUG A little advertisement: Cincom pushed the idea to have a lawyer at ESUG to explain such kind of points, there will be a panel with Julian Fitzel, Bert Freudenberg so we will all learn. Prepare your questions. /ESUG On Aug 30, 2010, at 10:40 AM, Johan Brichau wrote: Hi Andreas, I am not a lawyer but as far as I understand this topic, no license means nobody can use the code at all, which contradicts the fact of having it in a public repository (and you being perfectly happy of people using it). Can you please clarify the license situation of those projects? Best regards, Johan On 30 Aug 2010, at 00:00, Andreas Raab wrote: 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. ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010 00:24:37 -0700 Stéphane Ducasse wrote 3- Philippe contacted you with fixes several times and got no reply, sven too so people thought that you do not want to talk to them. Apparently not so this is good. Andreas was having mail issues. A few days ago I emailed him a small WebClient package after discussing a feature with him on Squeak-Dev. I left a note on the mailing list telling him about it, and he replied saying that he never got it. I sent it again, and he informed me after doing some digging that it and other emails bearing attachments had gotten caught in his spam filter. If you don't get a response from him, send your email again or leave a message on Squeak-Dev. Andreas has shown a great willingness to cooperate and accept patches to make WebClient cross-compatible with Pharo. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Stéphane Ducasse wrote: Hi pharoers What do you think? I think that we should not have any software parts whose license is not set clearly in Pharo. So I will remove WebClient from Pharo. 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? What's wrong with one that could be shared by all Squeak forks? Levente Stef On Aug 30, 2010, at 12:00 AM, 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
ok On Aug 30, 2010, at 12:01 PM, jaayer wrote: On Mon, 30 Aug 2010 00:24:37 -0700 Stéphane Ducasse wrote 3- Philippe contacted you with fixes several times and got no reply, sven too so people thought that you do not want to talk to them. Apparently not so this is good. Andreas was having mail issues. A few days ago I emailed him a small WebClient package after discussing a feature with him on Squeak-Dev. I left a note on the mailing list telling him about it, and he replied saying that he never got it. I sent it again, and he informed me after doing some digging that it and other emails bearing attachments had gotten caught in his spam filter. If you don't get a response from him, send your email again or leave a message on Squeak-Dev. Andreas has shown a great willingness to cooperate and accept patches to make WebClient cross-compatible with Pharo. ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. This is not our own library, this is a library we can contribute, control 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. Now I was not even aware of the ConfigurationOfWebClient. There is none in the squeaksource repository. So how can we guess? I'm not reading squeak-dev and no idea that there is even somebody using metacello. What's wrong with one that could be shared by all Squeak forks? We do not have problem with sharing. You can take anything you like from Pharo. Seaside, Magritte, Pier, RB, are all MIT OB is MIT and lukas pushed it a lot recently for everybody. Moose is BSD, MIT, Glamour, Mondrian MIT ... and I'm sure that they are more. :) they are all external projects. We discussed on the mailing-list what to do and people thought that it would be good to get in included it. Probably we missed the point that we just need SocketStream to load the rest. I'm dull but learning everyday. For me I just cannot stand HTTPSocket and the network package so anything is better. But may be it was a mistake. Note that I hope that squeakers will not bash us as the guys that want to play it alone because this is not the case, but people can bash us if this helps them to feel good. Pharo is there for that too ;D. WebClient was the perfect case for sharing but Andreas decided differently. Now - since the license is unclear - since the license of the contributors is unclear we will not use it as an infrastructural assets for Pharo. I imagine that Seaside will not use it either. Stef Levente Stef On Aug 30, 2010, at 12:00 AM, 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.
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. This is not our own library, this is a library we can contribute, control You can contribute to WebClient, but you don't have full control, just like any external packages. 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. Now I was not even aware of the ConfigurationOfWebClient. There is none in the squeaksource repository. It's in MetacelloRepository. So how can we guess? I'm not reading squeak-dev and no idea that there is even somebody using metacello. Well, Squeak users also use Metacello. Dale is kind enough to maintain Metacello configurations for Squeak too. What's wrong with one that could be shared by all Squeak forks? We do not have problem with sharing. You can take anything you like from Pharo. Seaside, Magritte, Pier, RB, are all MIT OB is MIT and lukas pushed it a lot recently for everybody. Moose is BSD, MIT, Glamour, Mondrian MIT ... and I'm sure that they are more. :) they are all external projects. We discussed on the mailing-list what to do and people thought that it would be good to get in included it. Probably we missed the point that we just need SocketStream to load the rest. I'm dull but learning everyday. For me I just cannot stand HTTPSocket and the network package so anything is better. But may be it was a mistake. Note that I hope that squeakers will not bash us as the guys that want to play it alone because this is not the case, but people can bash us if this helps them to feel good. Pharo is there for that too ;D. WebClient was the perfect case for sharing but Andreas decided differently. I think he didn't decide yet, but prove me wrong. Now - since the license is unclear - since the license of the contributors is unclear we will not use it as an infrastructural assets for Pharo. I imagine that Seaside will not use it either. 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. Levente *The benchmark is done with 50 concurrent users, clicking the counter example as fast as they can: Label Throughput (kB/s) Average response time (ms) Squeak-Kom 69.53 690 Squeak-WebClient105.46 447 Cog-Squeak-Kom 74.54 617 Cog-Squeak-WebClient226.80 193 I didn't include the Pharo results, because when we did the benchmark, there was no Cog support for Pharo. The max response time for Cog-Squeak-WebClient (575ms) was less than the average of Cog-Squeak-Kom. Stef Levente Stef On Aug 30, 2010, at 12:00 AM, 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
Re: [Pharo-project] 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#,. Philippe (an expert in writing platform independent code) and Sven have fixed all these issues so that the code works flawlessly on both platforms, Squeak and Pharo. 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. I guess that means the long-term plan of replacing HttpSocket in Squeak is out as well? 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. If you call (re)introducing #squeakToUtf8/#utf8ToSqueak instead of using convertTo/FromEncoding: 'utf8', then yes. 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] WebClient-Core port to Pharo 1.1 final
Before some of us are continue to lament or are too quick in decisions like removing/forking/reimplementing the web lib or judging on all this I think it would be wise to wait for a response from Andreas. First: his response was directly to Sven (with Pharo in CC) and please reread what he wrote: which are not (or not yet) under MIT. Which means there is a chance that the code will be under MIT. But as he wrote: that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion It is fairly reasonable to discuss it first since all our time is limited and the more forks we have the more time may be wasted. A fork would only be necessary if Squeak and Pharo differ too much in the underlying base. Which again leads to the question if it would be possible to reshape both systems onto a common clean kernel ... but thats another story. I think that even a fork of a package would be no problem (you can hardly prevent it when you set something real open source) but there should be a way that contributions/fixes can be folded back into the original (external) code stream. your repository incorrectly claims that the version of WebClient in it is LGPLv2. Yes, Sven uploaded a WebClient-Core-Sven72.mcz to squeaksource/ADayAtTheBeach and this repository is LGPLv2. Andreas was just surprised that someone relicensed his code even before he has put a license tag onto the original package. Same for the inclusion into the MIT licensed Pharo core image. On the other hand he published ConfigurationOfWebClient-ar.1.mcz into the MIT licensed squeaksource/MetacelloRepository instead of keeping the Configuration into the unlicensed package repository. So it looks like he wanted to do an MIT release ... However: Andreas has to put a license tag onto his code so we can finally stop this whole side discussion and continue to move forward nobody in Pharo even tries to find out what the license status for WebClient is. Yes ... looks like there was/is a missing/incomplete process in license checking In short, my position is that we need more shared libraries, not more forks +1 I think WebClient should be an external package External - Internal is just a question of a modularized image and loading/unloading. In case of Andreas deciding for MIT and a code integration into the base images (Squeak, Pharo, ...) the community has one leading place for the code (the external package). Similar to what I do for HelpSystem. So Managing the code external is OK since this would allow all us all to load it into own custom images or merge changes into own custom adoptions (if they are necessary). In case Andreas decides for non-MIT there is no option - the community has to find a more open alternative if it wants to include it in Pharo or even port it to other Smalltalk systems (for instance to reuse the code in conjunction with Seaside on VW/VAST/...) My 2cent Bye T. -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 euro;/mtl.!* http://portal.gmx.net/de/go/dsl ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 ) I think that we integrated all the socketStreams fixes last week or so. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
We do not want a process/system where one single person controls something important. - first it does not scale. - second it is not good for the ecosystem feeling. - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because we could not touched graphics and we needed to integrate other fixes) and we do not want that again. - fourth we are reading to share and we know how to do it but not at any price. Now I have to work. :) Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Stéphane Ducasse wrote: We do not want a process/system where one single person controls something important. - first it does not scale. - second it is not good for the ecosystem feeling. - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because we could not touched graphics and we needed to integrate other fixes) and we do not want that again. - fourth we are reading to share and we know how to do it but not at any price. It's a bit funny to read that from a benevolent dictator. Levente Now I have to work. :) Stef ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. http://code.google.com/p/pharo/issues/list?thanks=2885 Thanks ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
We do not want a process/system where one single person controls something important. - first it does not scale. - second it is not good for the ecosystem feeling. - third we got burnt in the past (remember 3.9 fonts problems - 3.9 was shipped with bug because we could not touched graphics and we needed to integrate other fixes) and we do not want that again. - fourth we are reading to share and we know how to do it but not at any price. It's a bit funny to read that from a benevolent dictator. I'm happy that this makes you smile. Apparently you did not study enough history... if we can call that history. Then you probably do not read not well enough this list because we always discuss and I often do not have hard thoughts. I'm trying to learn from people and more act as a catalyst. Our process is not close we just do a simple quality control. Now you can do whatever you want with your software, I will not argue on that. Now I prefer to talk with you about software and not things that are too emotional, because I learn more from it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Thanks It skipped my radar since it is not marked as fixed. do you want that I add you to the project developers on google so that you can changed the tag value? Stef On Aug 30, 2010, at 3:35 PM, 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. ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Johan Brichau wrote: I am not a lawyer but as far as I understand this topic, no license means nobody can use the code at all, which contradicts the fact of having it in a public repository (and you being perfectly happy of people using it). IANAL. no license means it's public domain, so *anybody* can use it. But, if they use it, they have no idea of the terms under which they can use it - a license would may the terms clear. Cautious users would then *not* use it. So the net effect would be that nobody (that is cautious) uses it. There is no contradiction with it being in a public repository. The author is perfectly happy for the public to use it. The problem is that users are likely not happy to use it, without any license terms. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. We should learn how to integrate things without intimately tying everything with a single bloated image. And WebClient could be right thing for learning that (Seaside too ;). -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
El lun, 30-08-2010 a las 13:06 +0200, Levente Uzonyi escribió: 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. This is plain wrong, You CAN'T make something open source and at the same time hope that nobody will fork it. The possibility of forking is one of the main liberties granted by the free and open source software. If Andreas doesn't want anyone to fork then by definition can't be open source. As I said before, a way to avoid forking in an open source project is to be open and accepting code from contributors. Not accepting good code for bad reasons is what leads to forking. I, and I think, every Pharo user, are ok with the package being controlled by Andreas, as long as the patches are accepted and not rejected for bad reasons (like having the package part of pharo core: that is our problem, if there are issues by having it part of pharo core we'll solve them, without bothering Andreas because they are Pharo specific. But he can't also, by the same Open source nature, restrict the uses of the code). We all, greatly respect and admire his technical ability, that has never been denied. But his public interactions has more than one burned a lot of people, and this no-license issue is becoming one of them. We don't want tramps like that of the missing license. When the code was announced it was a public encourage to use it and test it, but we as community went to happy and without checking the license it was included in pharo. That was our error. So please, Andreas, if you want WebClient to be open source please do it, Pharo will use it and send you patches. If not say it too, and we'll find an alternative for this. Cheers -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/8/30 Miguel Enrique Cobá Martínez miguel.c...@gmail.com: 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. Then you making things wrong, because then: - party A made feature A available - party B made feature B available - users want A and B features both, but party A and B do not communicate I think that Andreas wants to impose a teamwork, when multiple parties working on same project, rather than multiple parties working on each own fork of a same project. I think i understood the Anreas'es point well. As initial developer, he dont wants to be in position, when his creation moves into a different direction, than he is initially planned. At least, until Andreas to-do list is not empty, and project is not mature enough, it is wise to keep development under his personal control. That's how i understood his message about license. 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/8/30 Miguel Enrique Cobá Martínez miguel.c...@gmail.com 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 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
thanks henrik I always learn something :) 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: 10 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 10 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 MediumDoc at: 2048 put: $å. [1 to: 10 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 1451 1438 [1 to: 10 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 1463 1470 Cheers, Henry TextConverting.zip ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On 30/08/2010 12:06, Levente Uzonyi wrote: On Mon, 30 Aug 2010, Stéphane Ducasse wrote: Now - since the license is unclear - since the license of the contributors is unclear we will not use it as an infrastructural assets for Pharo. I imagine that Seaside will not use it either. Well, we are about to use it for Seaside. Is that legal? IANAL but it was my understanding that if code has no licence it means that noone but the author has any right to do anything with it whatsoever. Not to download it, use it or even read it. That's why licences explicitly grant you rights, because otherwise you have /none/. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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. That's why I personnally don't find Andreas defensive position a good strategy. Neither the attitude in response... It's like you're happy to throw his work away at first occasion without even trying to negociate. Bad vibrations. Before you engage in this (war)path, please, please, discuss. And remind this saying il ne faut pas confondre vitesse et précipitation. If no agreement is found then, ok, you'll get a license to carry on. 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 ? Please, discuss, argue, explain why you consider certain constructions as bad style. Propose alternatives (be constructive - remember coopetition ?). I consider being unable to explain one's own choice as a weakness. Don't be weak. Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Nicolas 2010/8/30 Mariano Martinez Peck marianop...@gmail.com: 2010/8/30 Miguel Enrique Cobá Martínez miguel.c...@gmail.com 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 Pharo-project@lists.gforge.inria.fr
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Aug 30, 2010, at 9:57 PM, Nicolas Cellier wrote: 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. why? because if there is a rewrite it will be MIT. That's why I personnally don't find Andreas defensive position a good strategy. Neither the attitude in response... It's like you're happy to throw his work away at first occasion without even trying to negociate. Oh no. I do not want that people bash us as people stealing work of other people. Read my mail on webClient. Bad vibrations. Writing all these mails is even more for me. Before you engage in this (war)path, please, please, discuss. And remind this saying il ne faut pas confondre vitesse et précipitation. If no agreement is found then, ok, you'll get a license to carry on. So far we talk in the desert. Loading WebClient is one line. So this is as easy as to remove. 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 ? I already suggested that. Now there is an important point. Infrastructure code should be supported, accessible to the community. We got burned with graphics andreas' onwership in the past. And yes we learned from that. Please, discuss, argue, explain why you consider certain constructions as bad style. Propose alternatives (be constructive - remember coopetition ?). I consider being unable to explain one's own choice as a weakness. Don't be weak. Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). I will let people decide as I did for the inclusion of webClient and we will rewrite one if necessary and it will be MIT. This will be the same for the equivalent of SqueakSSL we will try as much as possible to offer an infrastructure that let people control their life and make money. Our goal is to have a core that could be bootstrap so to have many packages as external as possible now I thought that it would help people to have webClient and also help us to remove this ugly network package. I should have know before the other HTTPClient library and we will not be here losing our time. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
This mailing-list is a public space. There are web archives all over the places and people can post without been in it. I want to avoid personal emails exchange. Now what should we run after him? Because the set up is like that no? Because I'm extremely busy so nobody has the luxury not to be not busy still I spent my morning trying to communicate. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Stéphane Ducasse wrote: This mailing-list is a public space. There are web archives all over the places and people can post without been in it. I want to avoid personal emails exchange. Now what should we run after him? Because the set up is like that no? Because I'm extremely busy so nobody has the luxury not to be not busy still I spent my morning trying to communicate. Just CC him. Levente Stef ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
(sorry, pine can't quote your mail correctly...) On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El lun, 30-08-2010 a las 13:06 +0200, Levente Uzonyi escribió: What I get from Andreas' words is that he's willing to make it open source if it won't be forked. This is plain wrong, You CAN'T make something open source and at the same time hope that nobody will fork it. The possibility of forking is one of the main liberties granted by the free and open source software. If Andreas doesn't want anyone to fork then by definition can't be open source. Maybe he'll be happy if you give your word that you won't fork it. As I said before, a way to avoid forking in an open source project is to be open and accepting code from contributors. Not accepting good code for bad reasons is what leads to forking. Sometimes you have to ignore/fix contributions. For example: - ProcessWrapper on SqueakSource had 2 new package versions which totally broke the package. I asked the contributor why he did the changes, but I got no response in a few days, so I just removed the versions. - PostgresV3 had a contribution, someone fixed a bug. The fix was a simple one-liner, but ignored the (untold) fact that PostgresV3 is meant to be fast, therefore critical methods are optimized by hand. So I had to rewrite to keep up with our goal. I, and I think, every Pharo user, are ok with the package being controlled by Andreas, as long as the patches are accepted and not rejected for bad reasons (like having the package part of pharo core: that is our problem, if there are issues by having it part of pharo core we'll solve them, without bothering Andreas because they are Pharo specific. But he can't also, by the same Open source nature, restrict the uses of the code). I don't think the problem was that the package is part of PharoCore. I think the problem was that Andreas wasn't asked about the inclusion and the package was forked and maintained in PharoCore. Levente We all, greatly respect and admire his technical ability, that has never been denied. But his public interactions has more than one burned a lot of people, and this no-license issue is becoming one of them. We don't want tramps like that of the missing license. When the code was announced it was a public encourage to use it and test it, but we as community went to happy and without checking the license it was included in pharo. That was our error. So please, Andreas, if you want WebClient to be open source please do it, Pharo will use it and send you patches. If not say it too, and we'll find an alternative for this. Cheers -- Miguel Cobá http://miguel.leugim.com.mx ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Henrik Johansen wrote: 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. Andreas may still decide to release the source under the MIT license. 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) So you can expect the code to be released under MIT, but maybe not now. :) 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. I mean, no converter objects are created. 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. More objects - more gc. It probably doesn't matter if the image doesn't have to handle heavy load. 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: 10 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 10 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 In Squeak(CogVM): 7-bit ByteString mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. === #(344 345 344 347 344) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(404 373 375 374 374) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1443 1440 1438 1443 1445) 7-bit ByteString with a single 8-bit character mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. mediumDoc at: 2048 put: (Character value: 128). (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. === #(1262 1246 1249 1250 1249). (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(1261 1256 1264 1260 1258) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | mediumDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(2591 2567 2538 2543 2582) Not neglible (~0.5 speed) 8-bit ByteStrings (only 1000 conversion/test) mediumDoc := ByteString new: 4096 streamContents: [ :stream | 4096 timesRepeat: [ stream nextPut: (Character value: 256 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix | mediumDoc squeakToUtf8 ] ] timeToRun ]. === #(627 618 618 622 618) (1 to: 5) collect: [ :run | [ 1 to: 1000 do: [ :ix |
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. Cheers Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Tue, 31 Aug 2010, Levente Uzonyi wrote: On Mon, 30 Aug 2010, Henrik Johansen wrote: snip MediumDoc is a pure ascii ByteString of size 4096 [1 to: 10 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 10 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 And another with SmallDoc: smallDoc := ByteString new: 20 streamContents: [ :stream | 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc squeakToUtf8 ] ] timeToRun ]. === #(15 15 15 15 15) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(34 34 34 35 32) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1256 1258 1259 1260 1260) smallDoc := ByteString new: 20 streamContents: [ :stream | 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. smallDoc at: 10 put: (Character value: 129). (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc squeakToUtf8 ] ] timeToRun ]. === #(115 112 112 113 112) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(157 125 124 126 125) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1416 1419 1419 1429 1428) Levente ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
GPL is designed to hold people (mostly commercial interests) hostage. Some of what is going on here sounds the same: it's open but not really. A web client is not so terribly difficult to write that we should compromise on licensing in order to use one. I have a *terribly* simple one that I can port if there is interest. IIRC, I used it to download some large files, but don't expect much. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [le...@elte.hu] Sent: Monday, August 30, 2010 6:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. From wikipedia: Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software. There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. See above. You could fork it, but that wouldn't be open source anymore. Levente Cheers Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Schwab,Wilhelm K wrote: GPL is designed to hold people (mostly commercial interests) hostage. Some of what is going on here sounds the same: it's open but not really. A web client is not so terribly difficult to write that we should compromise on licensing in order to use one. I have a *terribly* simple one that I can port if there is interest. IIRC, I used it to download some large files, but don't expect much. GPL was just an example for an open source license with restrictions, it has nothing to do with WebClient. Btw WebClient is far from simple (it's also a server, handles redirects, special responses, can support SSL, etc). Levente From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [le...@elte.hu] Sent: Monday, August 30, 2010 6:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Nicolas Cellier wrote: Hi Pharoers, snip Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Uh, what remark? Nicolas snip ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On 31.08.2010 00:34, Levente Uzonyi wrote: On Tue, 31 Aug 2010, Levente Uzonyi wrote: On Mon, 30 Aug 2010, Henrik Johansen wrote: snip MediumDoc is a pure ascii ByteString of size 4096 [1 to: 10 do: [:ix |MediumDoc squeakToUtf8]] timeToRun 362 384 [1 to: 10 do: [:ix | MediumDoc convertToEncoding: 'utf-8']] timeToRun 437 564 And another with SmallDoc: smallDoc := ByteString new: 20 streamContents: [ :stream | 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc squeakToUtf8 ] ] timeToRun ]. === #(15 15 15 15 15) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(34 34 34 35 32) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1256 1258 1259 1260 1260) smallDoc := ByteString new: 20 streamContents: [ :stream | 20 timesRepeat: [ stream nextPut: (Character value: 128 atRandom - 1) ] ]. smallDoc at: 10 put: (Character value: 129). (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc squeakToUtf8 ] ] timeToRun ]. === #(115 112 112 113 112) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToWithConverter: UTF8TextConverter new ] ] timeToRun ]. === #(157 125 124 126 125) (1 to: 5) collect: [ :run | [ 1 to: 10 do: [ :ix | smallDoc convertToEncoding: 'utf-8' ] ] timeToRun ]. === #(1416 1419 1419 1429 1428) Levente Yeah, that's why I added the 20 4KB docs / sec number. I really doubt the conversion will be a significant part of the processing time if what you send out is so small you are able to convert 800k messages per second... See the code I attached last mail, switching to convertToEncoding: 'utf8' sort of implied implementing something like that, which gives it nearly the same speed as convertToWithConverter: UTF8TextConverter new in your examples. IMHO, that might be a nice tradeoff between speed and the two desires of not bringing back #squeakToUtf8 in Pharo, nor having to use the convertToWithConverter: call Andreas was strongly opposed to (and which I agree is rather ugly). Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/8/31 Levente Uzonyi le...@elte.hu: On Mon, 30 Aug 2010, Nicolas Cellier wrote: Hi Pharoers, snip Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Uh, what remark? Oh, you know, the missinterpreted _and_... (that's wall I call lancer une pique). I should have included you in the list of people not having to answer ;) Nicolas Nicolas snip ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. From wikipedia: Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software. There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. See above. You could fork it, but that wouldn't be open source anymore. You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period. Levente Cheers Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
2010/8/31 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com: 2010/8/31 Levente Uzonyi le...@elte.hu: On Mon, 30 Aug 2010, Nicolas Cellier wrote: Hi Pharoers, snip Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Uh, what remark? Oh, you know, the missinterpreted _and_... (that's wall I call lancer une pique). wall - what, and I should go to bed, bye I should have included you in the list of people not having to answer ;) Nicolas Nicolas snip ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Tue, 31 Aug 2010, Henrik Sperre Johansen wrote: snip Yeah, that's why I added the 20 4KB docs / sec number. I really doubt the conversion will be a significant part of the processing time if what you send out is so small you are able to convert 800k messages per second... It depends on the machine/load/etc. See the code I attached last mail, switching to convertToEncoding: 'utf8' sort of implied implementing something like that, which gives it nearly the same speed as convertToWithConverter: UTF8TextConverter new in your examples. Sorry, I didn't see that. It looks cool, but I still wouldn't use #convertToEncoding: in my code, because there's a similar looking method (#converToWithConverter:) with better performance :). But it's definitely better than the current version, though if a converter is added/changed/removed, the dictionary has to be updated manually. Levente IMHO, that might be a nice tradeoff between speed and the two desires of not bringing back #squeakToUtf8 in Pharo, nor having to use the convertToWithConverter: call Andreas was strongly opposed to (and which I agree is rather ugly). 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Tue, 31 Aug 2010, Nicolas Cellier wrote: 2010/8/31 Levente Uzonyi le...@elte.hu: On Mon, 30 Aug 2010, Nicolas Cellier wrote: Hi Pharoers, snip Come-on guys, despite Levente's cutting remark, you're not inferior to squeakers ;) (and you don't have to answer to that stupid conclusion). Uh, what remark? Oh, you know, the missinterpreted _and_... (that's wall I call lancer une pique). It wasn't me who misinterpreted that and. I would agree with you, if I were using or, but that wasn't the case. I should have included you in the list of people not having to answer ;) :) Levente Nicolas Nicolas snip ___ 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El mar, 31-08-2010 a las 00:43 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Miguel Enrique Cobá Martínez wrote: El mar, 31-08-2010 a las 00:25 +0200, Levente Uzonyi escribió: On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. I don't get it. If it is open source then is forkable. Period. If it is a special case like GPL, it add some other restriction, like you can't redistribute the new code without it being also GPL. You can fork it and not using GPL for the new changes, the restriction is that you can't redistribute it. From wikipedia: Open-source software (OSS) is computer software that is available in source code form for which the source code and certain other rights normally reserved for copyright holders are provided under a software license that permits users to study, change, and improve the software. There's nothing about forking or redistributing here. I could make a license that says: you can study, change and improve the software, but you can't redistribute it without my permission. But the fact remains that it is forkable always. If you don't want it forkable, then use other non open source license. See above. You could fork it, but that wouldn't be open source anymore. You must be kidding. The freedom to fork is a essential right of open source software: http://news.cnet.com/8301-13505_3-10379280-16.html http://asay.blogspot.com/2006/10/wither-right-to-fork.html http://www.gnu.org/philosophy/free-sw.html http://www.opensource.org/docs/osd http://www.opensource.org/node/357 period. If you agree with OSI. Levente Levente Cheers Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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 -- Miguel Cobá http://miguel.leugim.com.mx ___ 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
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
On 31.08.2010 01:21, Levente Uzonyi wrote: On Tue, 31 Aug 2010, Henrik Sperre Johansen wrote: snip Yeah, that's why I added the 20 4KB docs / sec number. I really doubt the conversion will be a significant part of the processing time if what you send out is so small you are able to convert 800k messages per second... It depends on the machine/load/etc. I feel like we already had this discussion over the cull: implementation, and I doubt either of us is going to change their mind, so let's stop here :) See the code I attached last mail, switching to convertToEncoding: 'utf8' sort of implied implementing something like that, which gives it nearly the same speed as convertToWithConverter: UTF8TextConverter new in your examples. Sorry, I didn't see that. It looks cool, but I still wouldn't use #convertToEncoding: in my code, because there's a similar looking method (#converToWithConverter:) with better performance :). Sure, though I find it quite ugly, I wouldn't vehemently oppose using it either, but the issue here was finding something Andreas would accept :) But it's definitely better than the current version, though if a converter is added/changed/removed, the dictionary has to be updated manually. Levente Yeah, the code was merely a proof of concept to show off that you could get acceptable (for some :P) performance using it, as a middleground between squeakToUtf8 and convertToWithConverter in terseness. Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
Levente, I stand by the analogy of GPL's history and the more emotional undertones of the current discussion. Dismissing it won't make it go away. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [le...@elte.hu] Sent: Monday, August 30, 2010 6:47 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final On Mon, 30 Aug 2010, Schwab,Wilhelm K wrote: GPL is designed to hold people (mostly commercial interests) hostage. Some of what is going on here sounds the same: it's open but not really. A web client is not so terribly difficult to write that we should compromise on licensing in order to use one. I have a *terribly* simple one that I can port if there is interest. IIRC, I used it to download some large files, but don't expect much. GPL was just an example for an open source license with restrictions, it has nothing to do with WebClient. Btw WebClient is far from simple (it's also a server, handles redirects, special responses, can support SSL, etc). Levente From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [le...@elte.hu] Sent: Monday, August 30, 2010 6:25 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final On Mon, 30 Aug 2010, Friedrich Dominicus wrote: Levente Uzonyi le...@elte.hu writes: 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. Hm I think this is impossible. If it's OS it's up to whomever get its hand on it. Or am I mistaken? Just think about GPL, it's open source, but you can't fork the code if you don't release your changes as GPL too. Levente Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus ___ 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 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final
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
