You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <ol...@apache.org> on 2009/03/03 16:56:58 UTC
Re: Bringing the HttpCilent features up to parity with other
libraries / langauges
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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Bringing the HttpCilent features up to parity with other libraries
/ langauges
Posted by Oleg Kalnichevski <ol...@apache.org>.
James Abley wrote:
> Hi Oleg,
>
> I completed gzip and deflate yesterday. I'll create a ticket and submit a
> patch shortly.
>
> I haven't looked at the cache yet. If you want to suggest a SoC project for
> that, feel free.
>
> Cheers,
>
> James
>
Great! Content caching alone would probably be too small for a project.
I am looking forward to receiving the patch(es).
Cheers
Oleg
> On Mar 15, 2009 12:45 PM, "Oleg Kalnichevski" <ol...@apache.org> wrote:
>
> On Wed, 2009-03-04 at 21:57 +0000, James Abley wrote: > 2009/3/4 Tushar
> Kapila <tushar.kapila.2@gmai...
> James,
>
> How likely it is that you manage to find time and motivation to work on
> these features? The reason I am asking is that otherwise we could
> propose this as a project for the Google's Summer of Code 2009 program.
>
> Oleg
>
>> --------------------------------------------------------------------- > To
> unsubscribe, e-mail: ...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Bringing the HttpCilent features up to parity with other
libraries / langauges
Posted by James Abley <ja...@gmail.com>.
Hi Oleg,
I completed gzip and deflate yesterday. I'll create a ticket and submit a
patch shortly.
I haven't looked at the cache yet. If you want to suggest a SoC project for
that, feel free.
Cheers,
James
On Mar 15, 2009 12:45 PM, "Oleg Kalnichevski" <ol...@apache.org> wrote:
On Wed, 2009-03-04 at 21:57 +0000, James Abley wrote: > 2009/3/4 Tushar
Kapila <tushar.kapila.2@gmai...
James,
How likely it is that you manage to find time and motivation to work on
these features? The reason I am asking is that otherwise we could
propose this as a project for the Google's Summer of Code 2009 program.
Oleg
> --------------------------------------------------------------------- > To
unsubscribe, e-mail: ...
Re: Bringing the HttpCilent features up to parity with other
libraries / langauges
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2009-03-04 at 21:57 +0000, James Abley wrote:
> 2009/3/4 Tushar Kapila <tu...@gmail.com>:
> > Will be super to have gzip. I will be here to help with testing and some
> > docs, maybe unit test cases too. Am ok with app level code not really that
> > good with a library.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
> >
>
> Before I get too far into this, just wanted to confirm that I should
> base any changes on trunk and not on a branch? I expect to clone to
> git and make my changes accessible / let others see what's going on.
>
> Cheers,
>
> James
>
James,
How likely it is that you manage to find time and motivation to work on
these features? The reason I am asking is that otherwise we could
propose this as a project for the Google's Summer of Code 2009 program.
Oleg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Bringing the HttpCilent features up to parity with other libraries
/ langauges
Posted by Oleg Kalnichevski <ol...@apache.org>.
James Abley wrote:
> 2009/3/4 Tushar Kapila <tu...@gmail.com>:
>> Will be super to have gzip. I will be here to help with testing and some
>> docs, maybe unit test cases too. Am ok with app level code not really that
>> good with a library.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
>> For additional commands, e-mail: dev-help@hc.apache.org
>>
>>
>
> Before I get too far into this, just wanted to confirm that I should
> base any changes on trunk and not on a branch? I expect to clone to
> git and make my changes accessible / let others see what's going on.
>
Trunk. Anyways, you should not need to modify existing classes too much,
if at all. You should be able to add new functionality using existing
plug-in points. Compression should be implemented as a set of protocol
interceptors. Caching can be implemented through a decorator class for
the HttpClient interface.
Oleg
> Cheers,
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Bringing the HttpCilent features up to parity with other
libraries / langauges
Posted by James Abley <ja...@gmail.com>.
2009/3/4 Tushar Kapila <tu...@gmail.com>:
> Will be super to have gzip. I will be here to help with testing and some
> docs, maybe unit test cases too. Am ok with app level code not really that
> good with a library.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Before I get too far into this, just wanted to confirm that I should
base any changes on trunk and not on a branch? I expect to clone to
git and make my changes accessible / let others see what's going on.
Cheers,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Bringing the HttpCilent features up to parity with other libraries / langauges
Posted by Tushar Kapila <tu...@gmail.com>.
Will be super to have gzip. I will be here to help with testing and some
docs, maybe unit test cases too. Am ok with app level code not really that
good with a library.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Bringing the HttpCilent features up to parity with other
libraries / langauges
Posted by James Abley <ja...@gmail.com>.
2009/3/3 Oleg Kalnichevski <ol...@apache.org>:
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org