Re: store MD5 keys

Robert Collins wrote:

> There are a good reasons to have it there. It's very efficient for
> retrieval IFF you know the method. I'm becoming convinced that we need a
> two level retrieval structure - URL and metadata.

True.

> Henrik has neatly sidestepped the issue I'm facing with vary by placing
> a canonicalised description of the Vary: headers into the MD5
> calculations, and placing a dummy object that lists what headers to Vary
> on in the store index with nothing appended. I imagine that ETag can be
> done via an extension of the same - for Only-If-Match. However, getting
> the list of Etag's available is a similar proposition to invalidating
> all Vary: versions on a PUT.

The current ETag implementation extends this dummy object with internal entity
containing a index of all known ETag mappings for the URL.

For the time beeing this is a reasonable compromise. Normal requests are
handled in a flat structure, and only the few objects requiring this
secondary index are imparied by the added overhead.

The long term goal I thought we all have agreed on is to move much of this
down to the store layer, making storeGetEntryByRequest an async operation
allowing the store to do any kinds of complex lookups as required.

Regards
Henrik
Received on Mon Sep 09 2002 - 03:25:56 MDT