Re: store MD5 keys

On Mon, 2002-09-09 at 22:06, Henrik Nordstrom wrote:
> Robert Collins wrote:
> > On Mon, 2002-09-09 at 19:18, Henrik Nordstrom wrote:
> > > It is true that we need to unify HEAD and GET, but removing the request
> > > method won't solve the problem, only give you a whole bunch of other
> > > problems.
> > >
> > > There is more to this than variants and ETag. You also have to consider
> > > error messages and negative caching.
> >
> > Sure. I did not mean that we stop considering the method, just that it
> > should not be part of the store key lookup process.
>
> Then please explain again how you envision that to work in the current store
> model? Taking non-GET/HEAD methods and negative caching of these into the
> equation..

I'm not sure it will work in the current store model. At least, not
without potentially unacceptable memory overhead, xor a callback based
storeGetEntry.

The basic idea was to make the store key based on the URL alone contain
a list of all variants of that URL, varying by Etag or method.

So, when we retrieve the metadata about the object found at the URL, we
retrieve a list of objects, and can choose the object best suiting our
needs depending on what we need it for.

ie: PURGE: we release all of them.
general methods: we look for ones matching our method.
HEAD: we look for HEAD or GET methods.

Rob