dims 01/06/19 04:36:02
Modified: xdocs caching.xml
Log:
Added Caching.xml in xdocs from c2.0
Revision Changes Path
1.3 +52 -17 xml-cocoon2/xdocs/caching.xml
Index: caching.xml
===================================================================
RCS file: /home/cvs/xml-cocoon2/xdocs/caching.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- caching.xml 2001/06/19 11:31:33 1.2
+++ caching.xml 2001/06/19 11:36:02 1.3
@@ -1,19 +1,54 @@
-<?xml version="1.0" encoding="ISO-8859-1" ?>
-
-<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">
-
+<?xml version="1.0"?>
+<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
<document>
- <header>
- <title>Caching</title>
- <authors>
- <person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/>
- </authors>
- </header>
-
- <body>
-
- <s1 title="The Cache">
- </s1>
-
- </body>
+ <header>
+ <title>Caching</title>
+ <subtitle>in Cocoon 2</subtitle>
+ <version>0.1</version>
+ <type>Technical document</type>
+ <authors><person name="Carsten Ziegeler" email="[EMAIL PROTECTED]"/>
+ </authors>
+ <abstract>This document explains the basic caching algorithm of Cocoon
2.</abstract>
+ </header>
+ <body>
+ <s1 title="Goal">
+ <p>This document explains the basic caching algorithm of Cocoon 2.</p>
+ </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="Configuration">
+ <p>Configuration 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]
