cziegeler 01/06/22 02:12:54
Modified: xdocs Tag: cocoon_20_branch caching.xml
Log:
Small docs update
Revision Changes Path
No revision
No revision
1.1.2.5 +21 -30 xml-cocoon2/xdocs/caching.xml
Index: caching.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/xdocs/caching.xml,v
retrieving revision 1.1.2.4
retrieving revision 1.1.2.5
diff -u -r1.1.2.4 -r1.1.2.5
--- caching.xml 2001/06/22 08:35:35 1.1.2.4
+++ caching.xml 2001/06/22 09:12:54 1.1.2.5
@@ -16,35 +16,6 @@
</s1>
<s1 title="Overview">
<p>Overview is forthcoming</p>
-<p> Responsible for the caching are the CachingPipelines.
- When a sitemap is processed, this classes asking every
- sitemap component (generator, transformer,serializer)
- if they are cachable. If the component is cachable, it
- has to provide one key and one ValidityObject.
- Now the CachingPipeline builds from this provided keys
- one unique key for the pipeline and memorizes every
- ValidityObjects. The cache (interface EventCache/StreamCache)
- only stores CachedEventObjects and CachedStreamObjects.
- The key for those object is calculated one from the
- CachingPipeline.
-</p>
-<p>
-The concept of the caching is based on the various discussions and my own
thoughts...So here only a short overview:
-The sitemap components (currently Generator and Transformer) can implement the
Cacheable interface.
-This interface has two method:
-- generateKey() to generate a unique key within the space of the component ,e.g for
the FileGenerator
-this key is a hash of the source argument. (For this I added the HashUtil class
which provides the BuzHash algorithm).
-- generateValidity() the validity which checks if the cached content is still
valid, e.g. for the FileGenerator
- this is the TimeStamp of the xml file. The Caching Algorithm now checks all
pipeline components for the
- Cacheable interface and builds a unique key from these Components (starting from
the generator just to
- the point before the first not Cacheable component). This key is used to get a
CachedObject from the
-EventCache (actually a Store). The CachedObject (if available) contains the cached
content and all validity
-objects when this was cached. The next stage compares the current validity objects
with the cached ones.
- If they are all valid the cached response is used. If something failes during this
algorithm, a new response is
- generated and this result is cached. </p>
-<p>The storing of the sax events is implemented by two more
-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.
@@ -98,6 +69,12 @@
<p>Guess what! Yes, forthcoming.</p>
</s3>
</s2>
+ <s2 title="The XMLSerializer/XMLDeserializer">
+ <p>Forthcoming. Believe me!</p>
+<p>The storing of the sax events is implemented by two more
+Avalon components the XMLSerializer and the XMLDeserializer.
+</p>
+ </s2>
</s1>
<s1 title="Caching of stream pipelines">
<p>Forthcoming.</p>
@@ -109,7 +86,21 @@
<p>Description of the interfaces is forthcoming</p>
</s1>
<s1 title="Utility classes">
- <p>Description of HashUtil is forthcoming</p>
+ <s2 title="Hash Util">
+ <p>The <code>org.apache.cocoon.util.HashUtil</code> class
provides some
+ methods for the <link
href="http://www.serve.net/buz/hash.adt/java.000.html";>BuzHash algorithm by Robert
Uzgalis</link>.</p>
+ <source>
+ <![CDATA[
+ package org.apache.cocoon.util;
+
+ public class HashUtil {
+
+ public static long hash(String arg);
+ public static long hash(StringBuffer arg);
+ }
+ ]]>
+ </source>
+ </s2>
</s1>
</body>
</document>
----------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
