Re: [HttpCore] GZIP content compression in 'contrib' package

[Roland Weber <ht...@dubioso.net>]

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 :-)

>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?

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.

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

Re: [HttpCore] GZIP content compression in 'contrib' package

[Oleg Kalnichevski <ol...@apache.org>]

On Fri, 2006-02-03 at 19:38 +0100, Roland Weber wrote:
> Hi Oleg,
...
> 
> I am still a little itchy about the fact that such a clear distinction
> on the implementation level is not reflected in the interface hierarchy.
> But introducing tag interfaces without additional methods is pointless.
> JavaDocs will suffice.
> 

This is not that bad in fact. Consider GzipCompressingEntity class for
instance. As far as HTTP content compression is concerned this is
clearly a type of outgoing entity. However, it can also be used to wrap
an incoming entity on the client side in order to compress its content
prior to saving it in a database BLOB field. The same class is perfectly
usable in a different context, which is a good thing in my opinion

Cheers,

Oleg


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

Re: [HttpCore] GZIP content compression in 'contrib' package

[Roland Weber <ht...@dubioso.net>]

Hi Oleg,

> at the
> moment we should concentrate on getting the core modules to ALPHA
> release level first.

I fully agree.

>>>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.

Actually, the casting became necessary because you wanted to use classes
and interfaces on the server as well as on the client side. So you had to
define attributes and return values with the common interface, because the
associations request/outgoing and response/incoming apply only on the client
side and are reversed on the server side.
That design decision improved code re-usability and decreased the total
lines of code we need, so I fully support it.

> 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.

I've spent a few minutes thinking about merging the compressing and
decompressing entities into one class, but the result makes my brain
twist whenever I try to imagine a stack of entities. That's a sure sign
of a bad idea. Maybe I should publish an article about a new design pattern,
"Escher" :-)   http://www.mcescher.com/Gallery/back-bmp/LW389.jpg

I am still a little itchy about the fact that such a clear distinction
on the implementation level is not reflected in the interface hierarchy.
But introducing tag interfaces without additional methods is pointless.
JavaDocs will suffice.

> So true. I know I suck at writing documentation
> 
You fully compensate with the code :-)

cheers,
  Roland

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

Re: [HttpCore] GZIP content compression in 'contrib' package

[Oleg Kalnichevski <ol...@apache.org>]

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