On Tue, 2009-03-03 at 11:39 +0000, James Abley wrote:
> Hi,
>
> I've got a couple of suggestions that I thought might be worth kicking
> around here.
>
> I think that as an end-user of HttpClient, it demands too much
> knowledge of RFC2616. People shouldn't have to be aware of
> gzip-compression or other content-encodings that may be available,
> unless they want to specifically handle them.
>
> For example, Joe Gregorio's excellent httplib2 [1] for Python.
>
> >>> import httplib2
> >>> response, content = http.request('http://www.apache.org/')
>
> Using Wireshark, I can see that the request is made and supports
> compress and gzip encodings without the client developer having to
> know RFC2616 intimately or worry about handling the low level details
> like that.
>
> GET / HTTP/1.1
> Host: www.apache.org
> accept-encoding: compress, gzip
> user-agent: Python-httplib2/$Rev: 259 $
>
> httplib2 also has great in-built cache support and understands ETag /
> Last-Modified to transparently do conditional GET when required.
> Should conditional GET be handled by HttpClient? I think that it
> should; I think Restlet offers support for this. I'm sure there are
> other comparisons that could be made with other languages / libraries.
>
> I know that HttpClient 4 can offer support for gzip compression via a
> custom protocol interceptor (thanks Oleg!) but my personal view is
> that adds to the semantic surface area for a user of the API.
>
> Are these reasonable feature requests; i.e.
>
> 1. Good support for gzip Content Codings [2]. Others can be easily
> supported as well, but gzip is the most common.
> 2. Support a private cache / enable transparent conditional GET.
>
James,
These are reasonable feature requests for an average user's standpoint.
However, the main stumbling block is whether there is enough community
to sustain the expanded project scope. Who is going (a) write code, (b)
write unit tests, (c) write documentation for new functionality, (d)
monitor the user list for questions related to the new functionality,
(e) maintain code, at least mid-term? Even if you are prepared to
contribute the initial code drop (a), this is just not enough, unless
you are also willing to commit yourself to (b), (c), (d) and (e). Plus,
at least two existing project committers are also willing to do the
same.
Oleg
> Cheers,
>
> James
>
> [1] http://code.google.com/p/httplib2/
> [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
