Re: Bug #1893; why's it incomplete?

On fre, 2008-06-13 at 11:29 +0800, Adrian Chadd wrote:

> Ok, so where would you draw the line between client/server side stuff and
> storage stuff?

With or without major cleanup?

> Is it enough to be able to store multiple variants of the same object on
> some arbitrary keyset; and then place the Vary logic elsewhere?

Proper Vary operations needs the variants of the URL indexed by possibly
all three of the following:

  - Content-Location (if present). Needed to fulfill invalidation rules.

  - ETag (if present). Also need to be able to query for the list of
known ETag:s.

  - Vary request headers. With the ugly twist that there may be multiple
Vary combinations.. On objects with ETag these indexes 304 responses,
not variants. on objects without ETag the variant is located directly.

The operations needed on the cache is:

  - Which ETag:s is known on this URL?

  - Access object with ETag "X".

  - Cache this entity variant. Invalidates any other variants having the
same Content-Location.

  - PURGE everything known about this URL.

> Or would you want a lot of this logic to be in the store itself?

I would want most of it in a middle layer I think, sitting between the
http server protocol handler (client_side*) and forwarding. This layer
would be responsible for the logics needed for Vary and completion of
partial objects, with the store just providing the needed indexing, not
the logics.

The current situation is just to much of a mess to try continue patching
it up.

Regards
Henrik