Re: Hot object cache

On Mon, Oct 21, 2002, Henrik Nordström wrote:

> I think it is better to define another form of "store client" for this
> purpose, where data semantically is pushed to the client rather than
> retrieved by the client. Same mechanism should probably be used by both
> the on-disk and hot object caches.

I've given this a lot of thought, and the only solution I'm happy with is:

* the squid store layer has no idea of ranges, swapping in and out
* the store layers themselves make the decision
* when the store layers handle the index, they can make the decision whether
  an object reply is cacheable (as hno mentioned), and i ..
* prefer that the object reply isn't marked as cacheable until we've
  cached it - we can fix this later for (fat files, streams, etc.)

.. this may sound like the cheap and easy way out, but any other assumptions
limit what we're able to do.

Can we leave the store code alone as much as possible for the time being,
please? Is it possible to complete the fix_ranges code without playing
with the swapin/out logic? I'd like to play around with the async
storage API a little more first.

Adrian
Received on Sun Oct 20 2002 - 19:51:02 MDT