cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT]: Caching
Date Sat, 10 Nov 2001 13:16:10 GMT
Oh, the good old caching thread :)

Carsten Ziegeler wrote:
> 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.

Ok, IMO is fine to have a finer granularity on what cache implementation
to attach to any given pipeline.
> 2. You can use constructs/features which are not cache-safe. For
>    example using document() inside a stylesheet is such an example.

well, in theory, xalan could return us a list of URIs to check one it
compiles the stylesheet (of course, this is not part of JAXP at the
moment, so it could be a xalan-only feature). Well, anyway, this is to
say that it's not a limitation of the caching architecture but only an
implementation detail.

>    OK, as we are for separation of concerns using this function
>    is evil anyway. But what about xsl:import? And there might
>    be others.

Same thing. any xslt processor should implement it's own caching...
maybe we can work with the xalan guys to design the system that works
best for both projects.

>    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.

This is another concern at this point.

> 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.

And specify what caching algorithm to use.

> 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.

I like this. +1 from me.

> 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!

I like a) more.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

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

View raw message