gzipped images in SIAP 1.0 (fwd)

[Doug Tody]

On Thu, 31 May 2007, Patrick Dowler wrote:

> PS-Just as with FORMAT vs Content-Type, it is sub-optimal to have to initiate 
> the getData method to find out you won't be able to understand/decode the 
> data.

So should we discourage use of compression unless the HTTP client says
it can handle it with an Accept-Encododing header?

> However, putting both format and encoding in the query and/or response 
> should be recognised as an optimisation -- maybe a very useful one -- but not 
> required for correctness per se. It is almost like the course vs fine-grained 
> registry debate in some sense...

The following pertains only to client app-visible compression, e.g.,
something like FITS tiled-image compression, not HTTP-level compression.
In this case, once the service is done, we end up with a compressed
dataset which the client app has to be able to deal with.

If we describe this kind of compression in the query response, with
one query response record per available format, then we double the
size of the query response for every compression option.  Simple or
not, this starts to become unattractive.

Another possible way to deal with compression is merely to *enable*
dataset-level compression on the client side, and let the service
decide whether or not to return a compressed dataset.  Basically the
client is saying it can handle compressed data, but it doesn't care
what is delivered, and it will take compressed data or not depending
upon what the service wants to return.  This simplifies the interface
and avoids the need for the client to have to sort out the query
response and decide whether or not to retrieve a compressed or
uncompressed dataset.

This is pretty much what we had in mind for the COMPRESS parameter;
all it does is enable optional dataset-level (as opposed to transport
level) compression.  This would allow this feature to be used without
affecting clients that can't handle it.

	- Doug