xml-axkit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kip Hampton <khamp...@totalcinema.com>
Subject Re: [RFC] Altering the Execution Order in AxKit.pm
Date Fri, 14 Mar 2003 05:46:46 GMT
Jörg Walter wrote:
> 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?


View raw message