hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] GZIP content compression in 'contrib' package
Date Fri, 03 Feb 2006 17:30:04 GMT
On Fri, 2006-02-03 at 17:10 +0100, Roland Weber wrote:
> Hi Oleg,
> 
> I had a look at the GZIP content compression code. It's a good example
> for using the request and response interceptors, and for implementing
> content decompression.
> 
> In the *very* long run (not before we're running out of ideas what else
> is missing), we should reconsider wether to offer content decompression
> as part of the main package. I know that content handling is out of scope,
> but decompression is merely dealing with content representation. We do
> evaluate the charset attribute in the Content-Type occasionally, so we
> are already in the content representation business. Since we're not
> going to have the resources for implementing this anyway, I don't want
> to start a discussion now. I just wanted to have it mentioned once :-)
> 

Hi Roland,

I personally do not see a big problem in changing the project charter
provided it is clearly driven by the popular demand. However, at the
moment we should concentrate on getting the core modules to ALPHA
release level first. This issue is far from being a top priority one

> From the design point of view, I was surprised to see two different
> entities for compression and decompression. We had a long discussion
> about distinguishing incoming from outgoing entities and opted for a
> symmetrical interface in the end. Now, the distinction is creeping
> back in on the implementation level?
> 

I know we argued a lot about this one. Conceptually the idea of having
separate interfaces for incoming and outgoing entities was nice.
However, it practical terms such a design decision would imply having to
cast every HttpEntity instance to either interface in order to be able
to consume its content, which was way too much of a sacrifice for the
design purism's sake. So, we ended up having one interface to represent
all types of entities solely for practical reasons. Therefore I do not
see a big problem is having one way entity wrapper classes (representing
pure incoming or outgoing entities) on the implementation level.

> ResponseGzipCompress should have a short comment that it does not
> attempt to cover the full complexity of the spec: qvalues (gzip;q=0),
> wildcards or multiple Accept-Encoding headers.
> 

So true. I know I suck at writing documentation

Cheers,

Oleg


> Anyway, it is a good example as it is.
> 
> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message