On Tue, Nov 25, 2008 at 10:17 AM, Reinhard Pötz <[EMAIL PROTECTED]> wrote: > Peter Hunsberger wrote: >> On Tue, Nov 25, 2008 at 8:24 AM, Reinhard Pötz <[EMAIL PROTECTED]> wrote: >>> Grzegorz Kossakowski wrote: > > Could you elaborate on your caching requirements? >
We run an Intranet web app, (not a web site) with very complex dynamically assembled screens. We have fairly long pipelines, with a lot of aggregated components. There is almost always one component that cannot be cached at all (or makes little sense to cache) and the others have varying cache lifetimes. So currently we need to be able to pull cached SAX streams from the nonchanging components and run the results through XSLT as per standard Cocoon aggregated validity type checking. Any next gen version of our app will likely attempt to move this to a more granular approach using AJAX on the front end so it should be possible to eliminate most of, if not all of, the requirement for aggregated SAX via XSLT. However, even then, for a large chunk of our data we don't know exactly what can be shared until we examine security policies that are determined dynamically (eg, based on previous data requests) so we know we cannot move everything to http / web server type caching. Similarly, our cache invalidation policies are complex with hierarchies of dependencies so again you can't set simple http type cache expiiry policies, you've got to have something more like the current cocoon validity checking, where we can trigger a cascade of cache invalidation when some fundamental resource is updated. If that raises more questions than it answers I can attempt to elaborate... -- Peter Hunsberger
