2009/3/3 Oleg Kalnichevski <[email protected]>: > 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 >
Let's assume that (a) without (b) doesn't really exist! (c), well that's a bit scary! (d) and (e), can do. I'll checkout the code, sketch a few ideas and try to come back to the list with something. Cheers, James --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
