David J Woolley wrote:
>
> > What about a two way strategy? Storing two versions (one compressed and one
> > uncompressed) of the same object requires some additional disk space,
> > though it wouldn't require compression to take place for all but the first
> > high-level cache getting the uncompressed object data. Several checks to
>
> The correct place to compress is the origin server before putting the
> file onto the disk. The only issue for Squid should be whether to
> force Accept-Encoding and decode if not in the request. Decoding is
> designed to be much faster that encoding for the deflate (aka gzip)
> method.
This is a bit of a can-of-worms issue. I'm certainly in favour of
transfer-encodings. I think compression Is Cool(tm). However, this
automatically means supporting transfer-chunking, which (if you've
looked at the spec with a programmer's eye) is not all that appealing a
concept in many ways.
Also there are other issues if it is implemented:
* If squid supports a transfer-encoding that the server does, and the
client does not, should it use it? Or should it use the
lowest-common-demoninator (perhaps none).
* Squid cannot legitimately cache an object with transfer encoding,
unless it is prepared to retranslate it on the fly for a client that
wants it but does not support the encoding method it was cached with, or
unless the object is decoded before caching.
* What about the conversion of chunked transfers to non-chunked
transfers (if squid is speaking transfer-encoding to the server, and not
to the client)?
* What about conversion of non-chunked transfers to chunked transfers
(if squid is speaking transfer-encoding to the client, from an
non-encoded object)
* How do all these schema fit in with the data-pump design?
* Chunked transfers, interleaved in the persistent connection model. Fun
and games to please and delight the most discriminating, and no mistake.
Notwithstanding all of this, if any of you want to sit down and solve
these issues and contribute the code to squid, I'm sure it would be a
good thing. The rest of us are feeling a bit off-put by the whole
tangle, though.
D
Received on Wed Mar 17 1999 - 16:19:34 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:45:19 MST