Re: Hot object cache

On Mon, 2002-10-21 at 11:51, Adrian Chadd wrote:
> 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.

AFAICT this agrees with what I am proposing.
 
> Can we leave the store code alone as much as possible for the time being,
> please?

Yes.

> Is it possible to complete the fix_ranges code without playing
> with the swapin/out logic?

No.

> I'd like to play around with the async
> storage API a little more first.

This is orthogonal IMO.

Rob