cziegeler 01/06/20 07:47:42
Modified: xdocs caching.xml
Log:
Updated docs a bit
Revision Changes Path
1.4 +44 -1 xml-cocoon2/xdocs/caching.xml
Index: caching.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/xdocs/caching.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- caching.xml 2001/06/19 11:36:02 1.3
+++ caching.xml 2001/06/20 14:47:38 1.4
@@ -46,9 +46,52 @@
Avalon components the XMLSerializer and the XMLDeserializer.
</p>
</s1>
+ <s1 title="Caching of event pipelines">
+ <p>The algorithm used for caching depends on the configured event
pipeline.
+ For more information about configuration see the chapter below.</p>
+ <p>The following subchapters describe the available caching
algorithms.</p>
+ <s2 title="The CacheableEventPipeline">
+ <p>The CacheableEventPipeline used a very easy but effectiv
approach
+ to cache the event pipelines of a request: The pipeline process
+ is cached up to the most possible point.</p>
+ <p>Each sitemap component (generator or transformer) which might
be
+ cacheable must implement the Cacheable interface. When the
+ event pipeline is processed each sitemap component starting
with
+ the generator is asked if it implements this interface. This
+ test stops either when the first component does not implement
+ the Cacheable interface or when the first cacheable component
is
+ currently not cacheable for any reasons (more about this in a
moment).</p>
+ <p>The Cacheable interface declares a method
<code>generateKey()</code>
+ which must produce a unique key for this sitemap component
inside
+ the component space. For example the FileGenerator generates a
hash
+ of the source argument (the xml document read). All
parameters/values
+ which are used for the processing of the request by the
generator must
+ be used for this key. If, e.g. the request parameters are used
by
+ the component, it must build a key with respect to the current
request
+ parameters.</p>
+ <p>If for any reason the sitemap component detects that the
current request
+ is not cacheable it can simply return <code>0</code> as the
key. This has
+ the same effect as not declaring the Cacheable interface.</p>
+ <p>Now after the key is build for this particular request, it
is looked up
+ in the cache if it exists. If not, the new request is
generated and cached
+ for further requests.</p>
+ <p>To be continued...</p>
+ <s3 title="Example">
+ <p>Guess what! Yes, forthcoming.</p>
+ </s3>
+ </s2>
+ </s1>
+ <s1 title="Caching of stream pipelines">
+ <p>Forthcoming.</p>
+ </s1>
<s1 title="Configuration">
<p>Configuration is forthcoming</p>
</s1>
+ <s1 title="Java APIs">
+ <p>Description of the interfaces is forthcoming</p>
+ </s1>
+ <s1 title="Utility classes">
+ <p>Description of HashUtil is forthcoming</p>
+ </s1>
</body>
</document>
-
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
