W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: pack200-gzip Content Coding

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 10 Apr 2010 12:25:21 +0200
Message-ID: <4BC05211.30902@gmx.de>
To: Brian Smith <brian@briansmith.org>
CC: 'Mark Nottingham' <mnot@mnot.net>, 'HTTP Working Group' <ietf-http-wg@w3.org>
On 09.04.2010 16:40, Brian Smith wrote:
> ...
> Of course it is deployed and being used regularly. Anybody that uses
> WebStart should probably be using it, in fact. The encoding will only be
> applied to content of application/java-archive. It won't be applied to other
> content-types--in fact, for most content-types, it cannot be applied. So,
> there is no chance for things to go wrong.
>
> The only important requirement for a content-encoding is that there must be
> some function that maps any correctly-encoded entity into an unencoded
> entity. It isn't necessary to require that every content-encoding be able to
> transform any entity into an encoded entity; in particular, it isn't useful
> to require content-encodings to work for any/all content-types.
> ...

Understood. I misread the documentation; for some reason I read it to 
define something *like* a JAR-like archiving format, although it's 
really a way to post-process those.

My now hopefully correct understanding is that you pack200 the JAR file, 
then gzip the result, so the wrapping is like that

   gzip(pack200(JAR))

So pack200 is a compression that will work for JAR files (also ZIP?).

What I'm still not sure about is why they defined pack200-gzip, instead 
of just pack200 -- is there a concern that Content-Codings can't be 
nested? (This is the reason why content codings should get expert review 
and discussion on a public mailing list).

The other concern is that content codings are harder to deploy then new 
media types (IMHO), and thus it's not entirely clear why having a 
content coding that works with exactly one format is a good idea (as 
compared to just define a proper media type).

> The binary encodings of XML are a good example. If you were to make
> binary-encoded XML a content type instead of a content-encoding, then you
> would need new content-types for binary-encoded Atom, binary-encoded XHTML,
> binary-encoded SOAP, etc.

That's indeed a good example, and, as a matter of fact, many have argued 
that new media types would have been better. But in this case, it was 
arguably *easier* to just define a new content coding (as compared to 
many new types).

Best regards, Julian
Received on Saturday, 10 April 2010 10:26:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:18 GMT