[squeak-dev] Re: [Pharo-project] HTTPSocket

Phil (list) pbpublist at gmail.com
Tue Mar 3 03:29:24 UTC 2009


On Mar 2, 2009, at 9:16 PM, Keith Hodges wrote:

>
>> build server to innovate Rio for everyone rather than just for the  
>> image
>> I am using (trouble was I was using 3 different images), all I needed
>> was an inclusive attitude rather than an exclusive attitude.
>>
> Dear All,
>
> I was trying to implement FileHttpExecutive in Rio today, I wanted to
> perform a GET, and have Rio informed of the File size as soon as the
> headers have been downloaded. As an alternative it would also be  
> nice to
> be able to send a HEAD request prior to getting the whole file. I also
> want to read the stream as it is coming in, since Rio already can  
> buffer
> ftp reads direct to a file, or other destination.
>
> About 5 minutes looking at the code showed me that this was pretty
> impossible. There was no clean way to subclass HTTPSocket and have it
> hold a handle on my file instance and report that information to me,
> since most of the business is performed on the class side (why do  
> people
> do that?) My only option is probably to subclass HTTPSocket, inserting
> some Notifications in there, and use exception handlers to collect  
> the data.
>
> So... would anyone out there be willing to rewrite HTTPSocket/Client
> from scratch so that it is well designed and so on from the ground up?
> Assuming that Socket will remain common between Squeak/Pharo etc, it
> could also provide an abstraction onto the Curl plugin as well. This  
> new
> module would of course be for the benefit of all.
>

I too am looking for a better solution but haven't found one yet.  I  
am interested in looking at anything better if it exists and am  
willing to lend a hand to helping work on such an effort as well.

As I haven't found a solution yet, I have started to implement my own  
HTTPRequest and HTTPResponse classes which will (for now) be used as a  
front-end to a hacked up HTTPSocket.  The idea is that you would still  
have HTTPRequest get:, for example, but it wouldn't have the  
intermingled request/response handling code that HTTPSocket currently  
does and would provide more granular control of request servicing,  
support non-interactive reporting and handling of errors, and  
generally attempt to provide a clean front-end for HTTP that can be  
rewired transparently (from the callers perspective) to alternate  
lower-level network plumbing in the future.

> Has anyone done/is anyone doing this already?
>
> thanks in advance
>
> Keith
>
>


Not sure what your timeline on needing a solution is as I've just  
started this in the last couple of days but I'll be happy to share  
what I come up with once I have something more usable.  Also, if you  
have any specific recommendations or requests I am open to them.  If  
others interested in this, I would probably be willing to get a little  
crazy and even document it and provide some test cases.

Thanks,
Phil



More information about the Squeak-dev mailing list