Return-Path: Delivered-To: apmail-xml-cocoon-cvs-archive@xml.apache.org Received: (qmail 72182 invoked by uid 500); 22 Jun 2001 09:12:55 -0000 Mailing-List: contact cocoon-cvs-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: cocoon-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list cocoon-cvs@xml.apache.org Received: (qmail 72173 invoked by uid 500); 22 Jun 2001 09:12:54 -0000 Delivered-To: apmail-xml-cocoon2-cvs@apache.org Date: 22 Jun 2001 09:12:54 -0000 Message-ID: <20010622091254.72169.qmail@apache.org> From: cziegeler@apache.org To: xml-cocoon2-cvs@apache.org Subject: cvs commit: xml-cocoon2/xdocs caching.xml 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 @@

Overview is forthcoming

-

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. -

-

-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.

-

The storing of the sax events is implemented by two more -Avalon components the XMLSerializer and the XMLDeserializer. -

The algorithm used for caching depends on the configured event pipeline. @@ -98,6 +69,12 @@

Guess what! Yes, forthcoming.

+ +

Forthcoming. Believe me!

+

The storing of the sax events is implemented by two more +Avalon components the XMLSerializer and the XMLDeserializer. +

+

Forthcoming.

@@ -109,7 +86,21 @@

Description of the interfaces is forthcoming

-

Description of HashUtil is forthcoming

+ +

The org.apache.cocoon.util.HashUtil class provides some + methods for the BuzHash algorithm by Robert Uzgalis.

+ + + +
---------------------------------------------------------------------- In case of troubles, e-mail: webmaster@xml.apache.org To unsubscribe, e-mail: cocoon-cvs-unsubscribe@xml.apache.org For additional commands, e-mail: cocoon-cvs-help@xml.apache.org