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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
