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.