Oh, I forgot one problem: using java extensions in a stylesheet is also not cache-safe!
Carsten > -----Original Message----- > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 09, 2001 9:32 AM > To: Cocoon-Dev > Subject: [RT]: Caching > > > The current caching implementation of Cocoon is a ever or never > approach. This means you can either turn on caching for the > whole site or turn it off. (However turning on caching does > not mean that everything is cached. This depends of course on > the used sitemap components etc.). > > > I see two main problems with this approach: > 1. There are situations (or pipelines) where you know that they > should not be cached. But you don't want to turn off caching. > So we need more fine tuning of caching as always on or never > on. > > 2. You can use constructs/features which are not cache-safe. For > example using document() inside a stylesheet is such an example. > OK, as we are for separation of concerns using this function > is evil anyway. But what about xsl:import? And there might > be others. > Now, if you use such a function and you change the included/ > imported resource, the caching algorithm has no change to > detect this and therefore a response will still be served > from the cache and you get an old (or invalid) response > which does not reflect the changes. > > Now I see three possible solutions: > a) As Giacomo suggested several months ago, we could define > for each map:pipeline if it should go into the caching > algorithm or not. I think, the original proposal suggested > to define which stream and event pipeline should be used. > So you configure sets of these in the cocoon.xconf, like: > <pipelines default="caching"> > <pipeline name="caching"> > <stream-pipeline > src="org.apache.cocoon.components.pipeline.CachingStreamPipeline"/> > <event-pipeline > src="org.apache.cocoon.components.pipeline.CachingEventPipeline"/> > </pipeline> > <pipeline name="non-caching"> > <stream-pipeline > src="org.apache.cocoon.components.pipeline.NonCachingStreamPipeline"/> > <event-pipeline > src="org.apache.cocoon.components.pipeline.NonCachingEventPipeline"/> > </pipeline> > <pipeline name="half-caching"> > <stream-pipeline > src="org.apache.cocoon.components.pipeline.NonCachingStreamPipeline"/> > <event-pipeline > src="org.apache.cocoon.components.pipeline.CachingEventPipeline"/> > </pipeline> </pipelines> > (This example currently does not care about the usual Avalon > configuration rules for the cocoon.xconf). > And inside the sitemap you could simply write: > <map:pipeline type="non-caching"/> etc. When the type attribute is > missing the > default is used. > > This approach is very flexible as you could not only turn > on/off caching > for parts of the sitemap but use different combinations of event and > stream > pipelines in the various parts - for example if you have different > caching strategies etc. > > b) Provide a sitemap construct to override the caching information set by > the > sitemap component. Usually a sitemap component like the file > generator or > the xslt transformer state that they are Cacheable and that they can > cache the current request. > Now if you use document()/xsl:import etc. you know this and you could > say when your stylesheet is used in the pipeline that this is not > cacheable. > Something like: > <map:generate src="file.xml"/> > <map:transform src="evil_stylesheet.xsl" cacheable="false"/> > This extra attribute is evaluated by the caching algorithm and has > the same effect as if the sitemap component would not be cacheable. > > c) The same as b) but on a per component base. This means each sitemap > component defines itself if it allows to override the caching: > <map:generate src="file.xml"/> > <map:transform src="evil_stylesheet.xsl"> > <map:parameter name="cacheable" value="false"/> > </map:transform> > > Perhaps there are more solutions? > > Now, I think we could forget c) as we don't want that each component > implements > its own schema for this. > > Whereas a) requires changes in the component handling for the > pipelines, b) > does > not require this. However, both solutions are not incompatible with the > current > sitemap definition. > > So, I'm really interested in your opinions! > > > Carsten > > Open Source Group sunShine - b:Integrated > ================================================================ > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn > www.s-und-n.de mailto: [EMAIL PROTECTED] > ================================================================ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
