On Mon, 14 Apr 2003, Chris Leishman wrote: > > On Monday, April 14, 2003, at 10:07 AM, Matt Sergeant wrote: > > > On Sun, 13 Apr 2003, Chris Leishman wrote: > > > >> That isn't a very good general solution though.....eg. it wouldn't > >> work > >> with incr. caching. > > > > With Cache as a pipeline module (aka Language module) you wouldn't need > > the incr caching stuff. > > I think you need to explain the idea in more depth.....
OK, at the moment we cache at the end, prior to delivery. The cache has to try very hard to figure out if it should be applied or not (by checking mtime on every single resource involved in the transaction). This works well for direct pipelines of XSLT -> XSLT -> XSLT, but sucks for anything else. For anything involving XSP, it means you have no control. Caching is off. With incremental caching you get the magic of the current cache implementation, but happening at all stages in the pipeline. That can only be slower. What I'm trying to say is that I think I designed the caching system wrong, or at least "too smart". Instead I'd prefer the user to decide when the cache gets used (witness also the confusion about the cache being used despite changes in querystring). The sensible place for this to occur is another "stage" in the pipeline. So when you design your pipeline you choose where the caching occurs (hence no need for the incremental caching stuff as the cache becomes a manual thing). You also choose what things (other than files) affect the cache - like TTL, querystring, POST params, etc. This is not totally coherent yet, but hopefully its getting closer. -- <!-- Matt --> <:->get a SMart net</:-> Spam trap - do not mail: [EMAIL PROTECTED]
