cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject [RT]: Caching
Date Fri, 09 Nov 2001 08:31:53 GMT
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: cziegeler@s-und-n.de
================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message