On Tuesday, March 18, 2003, at 05:28 PM, Matt Sergeant wrote: <snip>
Right. At the moment the AxKit cache is all-or-nothing. You turn it off and it's off for the whole request. We don't cache in the middle.
Getting that right so that it doesn't cause too many cache checks in
pipeline is tough. I'm not entirely sure how to handle it. One idea that
sprang out of the AxKitB2B project was the user configures the cache to
happen wherever he/she wants it to. This worked well, but you lose
something because you now have even *more* to configure, and there's
probably too much to configure in AxKit already!
Still, it will probably all happen - it just needs tuits.
Ok. I don't see the problem with making the caching all-or-nothing (at least per pipeline) - but it would be nice to cache the output of intermediate stages in a pipeline.
Interestingly, this would suggest to me that it would be much more inefficient to have XSP earlier in the pipeline - since nothing after it can be cached.
The XSLT stylesheets can be cached (in memory, pre parsed).
Cool. But I meant 'nothing' as in 'none of the results of later processing stages'. Eg. if the source xml is dynamically generated via XSP, then the XSLT transformation would have to be reapplied.
Thanks again. And perhaps I'll look at that caching soon(ish).
Regards, Chris
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
