[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740049#action_12740049
 ] 

James Abley commented on HTTPCLIENT-834:
----------------------------------------

Oleg,

I hopefully described in the ticket why I think that this should work out of 
the box without requiring changes for existing clients. That's why I'm trying 
to get it working as part of the existing API.

If the functionality that I'm describing was done by adding a new 
ContentEncodingHttpClient, then what do we think the impact of this is? Would 
people need to alter their code (or maybe just Spring / Guice / etc 
configuration)? I think that complicates the API surface area and increases the 
semantic load on client developers. I don't think the clients should be 
required to know these details of the RFC;  application developers typically 
want to write code at a different level and expect that the library abstraction 
will do the right thing at its level.

I'm happy to write a version that subclasses as you suggest and see how it 
feels from a client perspective. Should that be based on trunk or the existing 
4.1 branch?

James

> Transparent Content Coding support
> ----------------------------------
>
>                 Key: HTTPCLIENT-834
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-834
>             Project: HttpComponents HttpClient
>          Issue Type: New Feature
>          Components: HttpClient
>    Affects Versions: 4.0 Beta 2
>         Environment: Any
>            Reporter: James Abley
>             Fix For: 4.1.0
>
>         Attachments: 834-2009-03-17.patch, 834-svn-754998.patch, 
> disable-content-coding.patch
>
>
> I would like to see HttpClient features brought up to parity with other 
> libraries, both in Java and other languages. c.f. Python's httplib2 (not yet 
> in the standard library, but many would like to see it in there). That 
> library transparently handles gzip and compress content codings.
> This issue is to capture possible solutions to providing this sort of innate 
> functionality in HttpClient, so that users aren't required to know RFC2616 
> intimately. The HttpClient library should do the right thing and use the 
> network in the most efficient manner possible.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to