On Tue, May 2, 2006 5:50 pm, Brian Akins said: > This seems more like a wish list. I just want to separate out the cache > and protocol stuff.
HTTP compliance isn't a wish, it's a requirement. A patch that breaks compliance will end up being -1'ed. The thundering herd issues are also a requirement, as provision was made for it in the v2.0 design. The cache must deliver what the HTTP cache requires (which in turn delivers what users require), not the other way around. Separating the cache and the protocol has advantages, but it also has the disadvantage that fixing bugs like thundering herd may require interface changes, forcing people to have to wait for major version number changes before they see their problems fixed. In this scenario, the separation of cache and protocol is (very) nice to have, but not so nice that end users are disadvantaged. >> - The ability to amend a subkey (the headers) on an entry that is >> already >> cached. > > mod_http_cache should handle. to new mod_cache, it's just another > key/value. How does mod_http_cache do this without the need for locking (and thus performance degradation)? How does mod_cache guarantee that it won't expire the body without atomically expiring the headers with it? >> - The ability to invalidate a particular cached variant (ie headers + >> data) in one atomic step, without affecting threads that hold that >> cached >> entry open at the time. > > mod_http_cache should handle. Entry invalidation is definitely mod_cache's problem, it falls under cache size maintenance and expiry. Remember that mod_http_cache only runs when requests are present, entry invalidation has to happen whether there are requests present or not, via a separate thread, separate process, cron job, whatever. >> - The ability to read from a cached object that is still being written >> to. > > Nice to have. out of scope for what I am proposing. new mod_cache > should be the place to implement this if underlying provider supports it. It's not nice to have, no. It's a real problem that has inspired people to log bugs, and very recently, for one person to submit a patch. Regards, Graham --
