[Pharo-project] Including Zinc HTTP Components in Pharo 1.2 Dev ?
Hi, Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ? In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant. Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option. I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code. What do you think ? Sven
Hi,
Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ?
In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant.
Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option.
I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code.
What do you think ?
big +1 I think you're doing a great job.
has a reasonable number of tests, has comments, is pretty small and elegant.
totally true to me, but as I'm not an expert nor an intensive user, my impression is just when reading your code and using it a bit. Same impression as XMLSupport ie. some reference packages... So I vote for inclusion :). Killing HTTPSocket class method is also important but as you said it can maybe wait... My 2cents Cédrick
Sven
I was just reading the code with olivier auverlot. I would love to have a small if possible replacement to the HTTPSocket Stef
Hi,
Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ?
In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant.
Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option.
I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code.
What do you think ?
Sven
On 07 Jan 2011, at 13:58, Stéphane Ducasse wrote:
I was just reading the code with olivier auverlot. I would love to have a small if possible replacement to the HTTPSocket.
There really is a lot of cleanup to do. The key/core replacement of HTTP client functionality is done, but HTTPSocket does so much stuff in such bizar ways that it will require a concerted effort of many people to clean it up. Then again, if Pharo won't do it, who will ? Sven
On Jan 7, 2011, at 20:10 , Sven Van Caekenberghe wrote:
On 07 Jan 2011, at 13:58, Stéphane Ducasse wrote:
I was just reading the code with olivier auverlot. I would love to have a small if possible replacement to the HTTPSocket.
There really is a lot of cleanup to do.
The key/core replacement of HTTP client functionality is done, but HTTPSocket does so much stuff in such bizar ways that it will require a concerted effort of many people to clean it up.
I guess that a lot of stuff isn't needed anymore and hence doesn't need to be reimplemented (?). We could deprecate such methods (or just delete them) and if later we figure some are really needed we can put them back again. I've quickly browser the references to HTTPSocket in PharoCore and there are not too many complicated ones, as far as I can tell. Adrian
As long as we don't remove HTTPSocket from scratch until two versions from now I see no problem :). On Fri, Jan 7, 2011 at 6:54 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
On Jan 7, 2011, at 20:10 , Sven Van Caekenberghe wrote:
On 07 Jan 2011, at 13:58, Stéphane Ducasse wrote:
I was just reading the code with olivier auverlot. I would love to have a small if possible replacement to the HTTPSocket.
There really is a lot of cleanup to do.
The key/core replacement of HTTP client functionality is done, but
HTTPSocket does so much stuff in such bizar ways that it will require a concerted effort of many people to clean it up.
I guess that a lot of stuff isn't needed anymore and hence doesn't need to be reimplemented (?). We could deprecate such methods (or just delete them) and if later we figure some are really needed we can put them back again. I've quickly browser the references to HTTPSocket in PharoCore and there are not too many complicated ones, as far as I can tell.
Adrian
On Jan 7, 2011, at 8:10 PM, Sven Van Caekenberghe wrote:
On 07 Jan 2011, at 13:58, Stéphane Ducasse wrote:
I was just reading the code with olivier auverlot. I would love to have a small if possible replacement to the HTTPSocket.
There really is a lot of cleanup to do.
Yes. Again infrastructure backbone work. Now since I want to work on/with pharo for a couple of years in the future, we will continue to improve.
The key/core replacement of HTTP client functionality is done, but HTTPSocket does so much stuff in such bizar ways that it will require a concerted effort of many people to clean it up.
Then again, if Pharo won't do it, who will ?
:) Stef
Hi Sven, +1 for Pharo 1.2 (the dev image) -1 for patching HTTPSocket (dev packages should not modify core code) For 1.3 we should think about integrating Zinc in PharoCore to replace HTTPSocket. Cheers, Adrian On Jan 7, 2011, at 11:05 , Sven Van Caekenberghe wrote:
Hi,
Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ?
In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant.
Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option.
I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code.
What do you think ?
Sven
On Jan 7, 2011, at 2:02 PM, Adrian Lienhard wrote:
Hi Sven,
+1 for Pharo 1.2 (the dev image) -1 for patching HTTPSocket (dev packages should not modify core code)
For 1.3 we should think about integrating Zinc in PharoCore to replace HTTPSocket.
Yes!
Cheers, Adrian
On Jan 7, 2011, at 11:05 , Sven Van Caekenberghe wrote:
Hi,
Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ?
In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant.
Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option.
I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code.
What do you think ?
Sven
Sven two questions: - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces. - do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP? Stef On Jan 7, 2011, at 11:05 AM, Sven Van Caekenberghe wrote:
Hi,
Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ?
In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant.
Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option.
I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code.
What do you think ?
Sven
I was in meeting all day, hence the late reply. On 07 Jan 2011, at 14:08, Stéphane Ducasse wrote:
Sven
two questions: - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces.
I don't think that would make a lot of sense: HTTP is a client-server protocol, the client and server sides have a lot in common; a split in three pieces would be possible but each piece would be rather small. Having the necessary pieces for a simple HTTP server present will lower the bar for others, so that makes sense too. (For example, the Seaside adaptor is really very little code, no more need for Kom unless you really want it).
- do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP?
Maybe, finding shared code can only be done by doing both implementations I'm afraid ;-) Another, related point is the following: maybe you noticed browsing the code that I have a number of classes in Zn that redo some standard functionality (ZnMimeType, ZnUrl, ZnCharacterEncoder, and some of the code in the utils classes), a bit like Seaside does. The reason is that the existing classes were broken beyond repair (IMHO), or that I was not confortable extending them. Now, if the existing classes could be improved/replaced, it would make sense to replace the Zn variant with a good system wide one. This is a search for the best solution. Sven
On Jan 7, 2011, at 8:07 PM, Sven Van Caekenberghe wrote:
I was in meeting all day, hence the late reply.
On 07 Jan 2011, at 14:08, Stéphane Ducasse wrote:
Sven
two questions: - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces.
I don't think that would make a lot of sense: HTTP is a client-server protocol, the client and server sides have a lot in common; a split in three pieces would be possible but each piece would be rather small. Having the necessary pieces for a simple HTTP server present will lower the bar for others, so that makes sense too. (For example, the Seaside adaptor is really very little code, no more need for Kom unless you really want it).
Ok I was just thinking in them of what shoud we add to pharo-core to get mcz with http working
- do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP?
Maybe, finding shared code can only be done by doing both implementations I'm afraid ;-)
I will let olivier looking at your code and playing with his ideas and see what comes out.
Another, related point is the following: maybe you noticed browsing the code that I have a number of classes in Zn that redo some standard functionality (ZnMimeType, ZnUrl, ZnCharacterEncoder, and some of the code in the utils classes), a bit like Seaside does. The reason is that the existing classes were broken beyond repair (IMHO), or that I was not confortable extending them.
I agree.
Now, if the existing classes could be improved/replaced, it would make sense to replace the Zn variant with a good system wide one. This is a search for the best solution.
Yes this is great.
On 7 January 2011 20:07, Sven Van Caekenberghe <sven@beta9.be> wrote:
I was in meeting all day, hence the late reply.
On 07 Jan 2011, at 14:08, Stéphane Ducasse wrote:
Sven
two questions: Â Â Â - if we want to use zn for pharo to replace HTTPSocket, don't you think that Zinc-HTTP-Client-Server should be split into pieces.
I don't think that would make a lot of sense: HTTP is a client-server protocol, the client and server sides have a lot in common; a split in three pieces would be possible but each piece would be rather small. Having the necessary pieces for a simple HTTP server present will lower the bar for others, so that makes sense too. (For example, the Seaside adaptor is really very little code, no more need for Kom unless you really want it).
   - do you think that some parts of zinc could be reused to implement other protocols such as POP, SMTP, IMAP?
Maybe, finding shared code can only be done by doing both implementations I'm afraid ;-)
Another, related point is the following: maybe you noticed browsing the code that I have a number of classes in Zn that redo some standard functionality (ZnMimeType, ZnUrl, ZnCharacterEncoder, and some of the code in the utils classes), a bit like Seaside does. The reason is that the existing classes were broken beyond repair (IMHO), or that I was not confortable extending them. Now, if the existing classes could be improved/replaced, it would make sense to replace the Zn variant with a good system wide one. This is a search for the best solution.
well it would be good to have these classes fixed, and make zinc using them. because these ones are needed thoughout entire system, and certainty, for things like mime-type , there could be code which can handle certain type(s), but know nothing about Zinc.
Sven
-- Best regards, Igor Stasenko AKA sig.
BTW it was thinking that the expected a JPEG should be more inadequate mimetype or something else. Stef getImageOfType: mimeType usingParser: parserClass fromUrl: urlObject | url stream request response | url := urlObject asZnUrl. stream := ZnUtils socketStreamToUrl: url. (request := ZnRequest get: url) setAccept: mimeType. response := self executeOneShot: request on: stream. response status = 200 ifFalse: [ ^ self error: 'Expected OK response' ]. response contentType = mimeType ifFalse: [ ^ self error: 'Expected a JPEG' ]. On Jan 7, 2011, at 11:05 AM, Sven Van Caekenberghe wrote:
Hi,
Maybe I am a bit late with this question, I also don't know who makes the decision, and it is probably external people who have to make the judgement, but would it be possible and/or a good idea to include Zinc HTTP Components into Pharo 1.2 Dev ?
In any case, the code is in good shape, works on 1.2, has a reasonable number of tests, has comments, is pretty small and elegant.
Whether or not to load the Zinc-Patch-HTTPSocket package is another question. This package patches (destructively overwrites) class methods in HTTPSocket, redirecting them to ZnHTTPSocketFacade, effectively steering all HTTP client access in your Smalltalk image through Zinc HTTP Components. This has been working for me for months, but my usage is certainly not universal. So maybe this should remain an option.
I would especially like to expose this code to more people to get more feedback. I am also willing to keep on supporting the code.
What do you think ?
Sven
On 07 Jan 2011, at 14:14, Stéphane Ducasse wrote:
BTW it was thinking that the expected a JPEG should be more inadequate mimetype or something else.
Stef
getImageOfType: mimeType usingParser: parserClass fromUrl: urlObject | url stream request response | url := urlObject asZnUrl. stream := ZnUtils socketStreamToUrl: url. (request := ZnRequest get: url) setAccept: mimeType. response := self executeOneShot: request on: stream. response status = 200 ifFalse: [ ^ self error: 'Expected OK response' ]. response contentType = mimeType ifFalse: [ ^ self error: 'Expected a JPEG' ].
Name: Zinc-HTTP-SvenVanCaekenberghe.111 Author: SvenVanCaekenberghe Time: 7 January 2011, 7:35:18 pm UUID: d633bf09-4617-4e34-b6c7-0260dc759817 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.110 fixed ZnClient class>>#getImageOfType:usingParser:fromUrl: to correctly report responses with unexpected mime types (Thx S.Ducasses)
Another one :) We were looking at the users of ZnUtils and I have the impression that it would be good to split it so that we get several groups of coherent users. there are the groups for - networking + constants - http ... so this way people could reuse the networking + constants parts for others protocols. Stef
;-) I was going to comment on this apparent 'counterpoint' asap! I think this shows Pharo is ripe for having something similar another Open Source project has called "Zip Picker"¹. We could have a simpler dev image which would have in a Welcome or similar space a picker (buttons or radio buttons) which select preconfigured Metacello scripts to download the complimentary packages for what the developer is interested in. my 0.01999... -- Cesar Rabak [1] DJGPP http://www.delorie.com/djgpp/zip-picker.html Em 07/01/2011 11:27, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu: Another one :) We were looking at the users of ZnUtils and I have the impression that it would be good to split it so that we get several groups of coherent users. there are the groups for - networking + constants - http ... so this way people could reuse the networking + constants parts for others protocols. Stef
On 07 Jan 2011, at 14:27, Stéphane Ducasse wrote:
Another one :)
We were looking at the users of ZnUtils and I have the impression that it would be good to split it so that we get several groups of coherent users. there are the groups for - networking + constants - http ... so this way people could reuse the networking + constants parts for others protocols.
Stef
Name: Zinc-HTTP-SvenVanCaekenberghe.112 Author: SvenVanCaekenberghe Time: 7 January 2011, 7:52:57 pm UUID: 845f67f8-df1c-40cf-a644-4699f50bc3bb Ancestors: Zinc-HTTP-SvenVanCaekenberghe.111 split of ZnNetworkingUtils from ZnUtils to separate related functionality (Thx S.Ducasses)
participants (7)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Cédrick Béler -
Guillermo Polito -
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe