--- On Fri, 9/5/08, Markus KARG <markus.karg_at_gmx.net> wrote:
...
> provide this. For the client side I think that the Jersey
> Client API should
> support it, since there is nothing like a client container
> outside of the
> Java EE world. The Jersey Client should transparently
> support compressed
> transports so the client application has nothing to deal
> with,
I agree in that there should be explicit support.
But I also think that client should have the option of disabling automatic uncompression, since there are cases where compressed form is more useful for the client. Default could still be automatic uncompression.
(apologies if I misunderstood your suggestion)
In my batch processing cases, highly compressable data (huge xml document) is best stored compressed on disk, and when fully downloaded (to prevent problems if transfer from s3 happened to fail due to network problems), processed using uncompressing streams. This both because processing is constrained by I/O (and hence read+uncompress is faster than read uncompressed) and to preserve disk space -- these are huge files.
I realize that this is probably not a very common use case, but thought I'll mention this anyway: it is good to have implicit support for automatic handling, as long as it doesn't prevent other use cases.
-+ Tatu +-