Re: Vary, store interface

Nope. storeGetPublicByRequest(request).

For range requests the request is a range. Where the actual range
processing takes place is another matter, but I think it belongs at a
higher level than the FS, but lower level than the client connection.

This is the interface to the generic Squid object store, not neccesarily
the FS implementation.

/Henrik

Robert Collins wrote:
>
> So do you see storeGetPublicRange for partials?
>
> ----- Original Message -----
> From: "Henrik Nordstrom" <hno@hem.passagen.se>
> To: "Adrian Chadd" <adrian@creative.net.au>
> Cc: <squid-dev@squid-cache.org>
> Sent: Thursday, January 18, 2001 7:53 AM
> Subject: Re: Vary, store interface
>
> > Adrian Chadd wrote:
> >
> > > You know, it might make sense to change the semantics of
> > > storeGet() to take a request_t or something.
> >
> > Did just that ;-)
> >
> > StoreEntry *storeGetPublicByRequest(request_t *);
> > StireEntry *storeGetPublicByRequestMethod(request_t *, method_t);
> > store_key *storeKeyPublicByRequest(request_t *);
> > store_key *storeKeyPublicByRequestMethod(request_t *, method_t);
> >
> > The old method are still used at some places, where no request_t
> > structure is available.
> >
> > > I'm just trying to see how we could extend the store interface here.
> >
> > Me too, at least in the long run. This excersise gives quite a bit of
> > light on what a full proper Vary implementation requires from the store.
> >
> > > The vary work is nice but I'd like it to sit under one interface.
> >
> > In the end I guess storeGet/storeOpen/whatever has to implement Vary,
> > and accept a request_t structure as input and work it out from there.
> > The other access methods should be killed I guess.
> >
> > There should also be a storeDelete interface working similarily. There
> > is a number of places where the cache needs to be purged even if no new
> > object are added. For example on methods known to modify the origin
> > server.
> >
> > /Henrik
> >
> >
Received on Wed Jan 17 2001 - 15:07:53 MST