On Tue, October 31, 2006 10:16 am, Issac Goldstand wrote: > How about implementing the providers as a filter (same API as normal > output filters, but separate chain just for mod_cache)? The final > filter in the chain destroys the buckets and the first can do any > "special handling" for special bucket types. Then in the existing cache > save filter, rather than passing the brigades to store_body as-is, we > would duplicate each bucket on the brigade, pass the original up the > output filter chain and then pass the duplicate up the cache chain (the > idea being to prioritize the client waiting; if it's a FILE bucket, the > network filter will SENDFILE it quickly, whereas the cache filters may > butcher the bucket with morphing, etc).
The trouble with this is that the backend, by definition, is expensive, while the cache, by definition, is cheap. (If not, then you shouldn't be using the cache). By copying the buckets you are effectively reading the expensive backend twice. I am not sure of the details of how CGI is handled, but that could also throw a spanner in the works. The way the cache solves this now, is that the expensive backend is read once, written to cache, then the cheap cache is passed to the network. > In addition to providing a more flexible API to the providers, this can > also help with the "stacked providers" idea that was mentioned a while > back[1]. Hmmm... I have also been thinking of how a caching module might be involved in the caching process, but not be the definitive cache provider. A good example is Brian Atkins' storing of cache metadata in a SQL database - the "write-to-sql" part should not mean that an entire cache provider be duplicated to do this. > [1] http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=114614668505950&w=2 Regards, Graham --
