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. > > The Provider's process() method is meant to indicate the Provider's > intention and ability to get data for the current resource. That's fine > and good, but for many non-file-based and/or dynamic Providers, > process() needs to do *everything* required to serve the data in order > to determine what to return (e,g. select from a DB-- return Declined if > there's no data, run the app that generates the content-- return > Declined if the app fails, or whatever). > > In practice, this means that by having AxKit.pm's main_handler() call > the Provider's process() before examining whether or not the resource is > cached, the Providers will *still* have to hit the database, run the > app, or whatever, even though the data for that resource may already be > cached on the disk-- hence, the real benefit of caching is taken away > from those Providers. > > Not a hard fix, I think, but I wanted to invite discussion and check my > blind spots before I whack into the main_handler() and friends.
Basically looks okay. Actually, I don't exactly understand the merits of process() anyways, since we have SetHandler/AddHandler. I never really got the difference between exists() and process(). 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? -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
