Steve Allen says:
> I would tread carefully until it is clear whether and when the FITS
> community at large is prepared for that sort of usage.
The bigger question is whether the FITS community is ready for a registry of conventions. Treading carefully is as much a watchword for FITS as for Col. Gadsden (http://en.wikipedia.org/wiki/ Image:Gadsden_flag.svg). (I'm writing this from his grandson's purchase.)
Tile compression is such a useful thing that one has hope it will drive application/fits to similar levels of utility. I still think it arguable that a tile compressed file be represented as image/fits - but by the time this is resolved, the meaning of application/fits will be similarly enhanced.
As usual, Doug clarifies the underlying issues:
> I think we need to keep two issues clearly separated here: 1) what
> the client application wants to see, and 2) what happens at the
> level of the HTTP protocol.
This is an admirable goal. I believe it is challenged on two fronts. The first is that mime-like semantics are insufficient to keep these separate. For instance, what does:
Content-Type: application/x-gzip Content-Encoding: gzip
(or Transfer-Encoding) require of the client? I won't further belabor the discussions to date.
The second issue is that efficient throughput is a function of the entire system, not just a separable transport layer, HTTP or otherwise. Ideally services should produce data benefiting from native compression such as FITS Rice tile compression. This compression could be applied with the first copy of the data, and could remain in effect all the way to the client. Even a client that requests gzip'ed formats must eventually uncompress the data to access header keywords as well as pixels. A client that requests tile compressed formats may frequently never need to uncompress those data. In those cases in which on-the-fly uncompression is needed, this is a much lighter weight function for tiled compression than for whole-file gzip.
Rob Received on 2007-05-30Z21:16:17