Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 77901 invoked from network); 23 Jan 2001 16:19:02 -0000 Received: from sundn.pb.teuto.net (HELO viruswall.ynes.de) (212.8.194.130) by h31.sny.collab.net with SMTP; 23 Jan 2001 16:19:02 -0000 Received: from 10.10.1.10 by viruswall.ynes.de (InterScan E-Mail VirusWall NT); Tue, 23 Jan 2001 17:18:37 +0100 (Westeuropaeische Normalzeit) Received: from hw0230 (fw-dmz.ynes.de [10.10.1.1]) by mail.ynes.de (8.9.3/8.9.3/NoSpam) with SMTP id RAA19472 for ; Tue, 23 Jan 2001 17:18:37 +0100 From: "Carsten Ziegeler" To: Subject: [C2]: Proposal for caching Date: Tue, 23 Jan 2001 17:21:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <20010123151105.7444bca2.scarvalho@criticalsoftware.com> Importance: Normal X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Hi, as I and some others are willing to implement a caching mechanism for = C2 I would like to force the implementation of it by starting a proposal. If we have finished the proposal, it could be implemented and then we have a solution which could be prooved. I reread all (or nearly) all of the mails regarding caching, most of = them were send in December. The comments, thoughs and proposals contained in = the mails lead me to this proposal, which is more or less a summary of what = was discussed then (I hope so at least).... OK, lets start: 1. Caching should not take place after each stage in the pipeline. 2. The most static part of the pipeline should be cached. 3. The logic for caching is either in the ResourcePipeline or "above" 4. If a component is cacheable it should implement an interface = Cacheable. 5. Caching is done until the first component in the pipeline is not = Cacheable. 6. Identifying if the cache contains the response (or the most static = part of it) can be done by a unique key. The Cacheable interface = implements a getKey() method. The keys of all Cacheable components are chained = together and build the unique key for the cache. 7. Cacheable also delivers a Validator object (getValidator()) which = contains all information required for this component to test if the content has = changed since the last caching. The FileGenerator e.g. puts the last modification date into the = Validator. The Cache stores all Validators together with the unique key. 8. All Cacheable components are now asked hasChanged(Validator). If all respond with false, the cache value is valid and is used.=20 If the first responds with true, a new response is generated, the = validators=20 are get and the result is put in the cache. This approach is very flexible. Each component nows if it is cacheable = and when it is invalid. Using the Validator object it is possible to specify = something=20 like: This component is really 6 hours valid wether it changes or not.