On Thu, 13 Mar 2003, Kip Hampton wrote: > Given this, I think that to cover the cases I'm trying to address, the > *Provider* has to maintain its own content cache, then decide within > itself whether to offer the cached copy of a resource or to reprocess to > generate new content-- any other solution is either too fugly or leads > to a brittle "chicken and egg" (which came first?) condition between the > Cache and Provider classes. If I can think of a way to do it generically > enough that other non-file-based/dynamic Providers can subclass and > benefit from, I'll whip it out for review. > > Anyone have more thoughts? Matt?
Like most things that poke this area of AxKit, I don't always understand the issues (mostly because I never got around to writing the axkit.com CMS, which is the whole reason I designed it the way it is, but because I never got around to developing it these subtleties never got uncovered). So I'm happy for you to do whatever is required as long as it doesn't break regular file use. Plus you can probably use the current AxKit::Cache module for doing provider level caching. -- <!-- Matt --> <:->get a SMart net</:-> Spam trap - do not mail: [EMAIL PROTECTED]
