Re: Vary, store interface

On Wed, Jan 17, 2001, Henrik Nordstrom wrote:
> 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.

Ok. Well, how about some help cleaning up the storeLookup() interface
to modio? Modifying it to take a request_t and making *everything*
that uses it take a request_t would be a big plus, and it'll make
merging in your work much easier down the track. :)

Adrian

-- 
Adrian Chadd			"Sex Change: a simple job of outside 
<adrian@creative.net.au>	  to inside plumbing."
				    - Some random movie