FWIW, in our earlier discussions we discussed segmented keys, that any
provider wouldn't have to provide multiple keys (to be hooked) but would
have to support segmented keys such that (for example) three UUID's would
designate highest - narrower - narrowest lookup, and it would (of course)
be expected that a segment 0-only lookup would have clashes/multiple
entities.
What a program does with this situation is up to the user/consumer. Our
thought was that if (for example http caching) we first did a direct seek
on -one- page based on segment 0 & 1 (the host and the uri) we would get
back the variant headers. We could then perform a direct hit on segment
0 & 1 & 2 (the variation key) and get precisely the page they needed as
a two-hit-always operation. If the page doesn't vary, the first hit would
be the actual page. If variant also varies, well, guess we are SOL ;-)
Bill
Brian Akins wrote:
An example I'd like to do (or mentor someone) is a mod_memcached that
could serve as the basis of memcached based modules. It could handle
all the configuration details, errors, and general heavy lifting of
memcached. It would then be very easy to write other modules that had
hooks into memcached (ie, a mod_cache provider).
Perhaps to abstract it even further, perhaps mod_memcached should be a
provider for a more generic caching framework. Not HTTP specific like
mod_cache, but a general key based cache. Could be used for a variety
of things (including an HTTP cache).
typedef struct {
apr_status_t (*cache_create)(ap_cache_t **instance, apr_table_t
*params);
apr_status_t (*cache_stats)(ap_cache_t *instance, ap_cache_stats_t
**stats);
apr_status_t (*cache_set)(ap_cache_t *instance, const char *key,
void *val, apr_size_t len, apr_time_t expires);
/*
other stuff, like get, replace, etc.
*/
} cache_provider_t;
Just "thinking out loud."
Also, mod_cache should be renamed mod_http_cache
