[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
|