Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 18854 invoked from network); 20 Dec 2003 04:29:06 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 20 Dec 2003 04:29:06 -0000 Received: (qmail 35267 invoked by uid 500); 20 Dec 2003 04:28:44 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 35223 invoked by uid 500); 20 Dec 2003 04:28:43 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 35210 invoked from network); 20 Dec 2003 04:28:42 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 20 Dec 2003 04:28:42 -0000 Received: (qmail 3744 invoked from network); 20 Dec 2003 04:28:47 -0000 Received: from unknown (HELO ?192.168.1.4?) (stefano@131.161.244.42) by pulse.betaversion.org with SMTP; 20 Dec 2003 04:28:47 -0000 Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: References: <264DFACA-2FA5-11D8-8A39-000393D2CB02@apache.org> <28936.1071601366@www48.gmx.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stefano Mazzocchi Subject: Re: Accessing cache validities from flow Date: Fri, 19 Dec 2003 18:11:42 -0500 To: dev@cocoon.apache.org X-Mailer: Apple Mail (2.606) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On 18 Dec 2003, at 05:27, Sylvain Wallez wrote: > We're talking about validities, but before checking a validity, we > first have to obtain it through the cache key. > In the current Cocoon architecture, keys of cache entries are built > with abitrary data defined by each of the individual pipeline > components. The result of this is that we can have several different > cached responses for a single request definition (URI + headers). Yes. > The big benefit of this approach is that many variations can be cached > (depending on night/day, local weather, whatever), but the main > disadvantage is that the pipeline *must* be built for every request in > order to compute the cache key, even if the response is served from > the cache afterwards. Very true. > A solution would be to have another pipeline implementation that uses > a different strategy to build cache keys. What comes to mind is that > instead of returning abitrary values for key, components could return > some matching criteria on request metadata. The pipeline could then > organize the cache entries by URIs, each URI having a list of cached > responses along with the matching criteria. > This approach would reduce the possible cached variations for a given > request, but would allow to find cached content (and its validity) > without incuring the cost of building the pipeline. > > What do you think? Hmmm, sounds very interestings, can you elaborate more on this? -- Stefano.