Re: pack200-gzip Content Coding

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 UTC