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]
