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]
