On Thursday, 13. March 2003 22:53, Kip Hampton wrote:
Howdy AxDevers...
I think I've stumbled over a subtle logic flaw in AxKit.pm's main_handler method as it relates to Providers and caching. The "problem" lies in the fact that the Provider's process() method is called before determining whether or not the resource is cached.
Though, does it make a difference? The cache needs to call mtime(),
which in turn is exensive as well... or not? Is there real money to be won, or is this just a matter of cleanlyness?
Well, my goal is to make things friendler for alternate Providers that have to perform heavier-duty operations in order to construct the resource's content but, whose content may be static enough to want to take advantage of caching where appropriate. After thinking more about it, though, it seems to me that there really *isn't* a flaw in the way things work now-- only a presumption that content will either be a static file or need to be generated for each request anyway.
Reality is that much of AxKit's behavior depends on the source content being parsed for every request (its how stylesheet PIs and most of the AxFooProcessor directives work) and what caching really avoids is the *transformation* overhead. The notion that the source of the content itself may be generated (and need to be cached in some cases) really isn't considered.
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?
-kip
