cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT]: Caching
Date Fri, 09 Nov 2001 08:34:06 GMT
Oh, I forgot one problem: using java extensions in a stylesheet
is also not cache-safe!


> -----Original Message-----
> From: Carsten Ziegeler []
> 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
>                      mailto:
> ================================================================
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message