Including Zinc HTTP Components in Pharo 1.2 Dev ?
Locked
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 > > > > |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
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 > > > > |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
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 > > > > |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
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 > > > > |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
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 > > > > |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
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 < [hidden email] > 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 |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Stéphane Ducasse
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) |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Stéphane Ducasse
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) |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Stéphane Ducasse
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 |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Stéphane Ducasse
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 |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
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 |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
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 <[hidden email]> wrote:
|
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Adrian Lienhard
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 >> >> >> >> > > |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
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. |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
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 |
Re: Including Zinc HTTP Components in Pharo 1.2 Dev ?
|
|
In reply to this post by Sven Van Caekenberghe
On 7 January 2011 20:07, Sven Van Caekenberghe <[hidden email]> 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. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |