From stefano@apache.org Thu Oct 5 17:55:54 2000 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 20992 invoked from network); 5 Oct 2000 17:55:54 -0000 Received: from pop.systemy.it (194.20.140.28) by locus.apache.org with SMTP; 5 Oct 2000 17:55:54 -0000 Received: from apache.org (pv25-pri.systemy.it [194.21.255.25]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id TAA01516 for ; Thu, 5 Oct 2000 19:55:52 +0200 Message-ID: <39DC7C6B.79E3AEDE@apache.org> Date: Thu, 05 Oct 2000 15:04:43 +0200 From: Stefano Mazzocchi Organization: Apache Software Foundation X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en,it MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [C2] Cache behaviour References: <39DB7FC7.9CB35903@mail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Ross Burton wrote: > > Hi, > > One of the problems with C2 was that no cache information was output to You mean C1, right? > the outside world, i.e. pages which never change and pages which change > ever 10 seconds have the same cache parameters in HTTP: none. Correct. The reactor designed didn't allow internal stages to have access to the response headers, this made impossible for producers (the owners of the caching concern) to provide caching information to the external world but only to the internal cache using hasChanged(). This was identified as a problem and this is why the Enviornment object in C2 provides access to both request and response to all stages (while protecting the output stream from all but serializers). > With C2 we can change this! Correct. > Somehow C2 needs to know the lifetime of > the data it is processing and include it with the HTTP headers. This > seems intimately related to the internal cache so it might be wise to > discuss these together... Yes, I agree. > So: how is the internal cache going to cache data, how will it know when > to refresh (are we keeping the C1 interfaces or creating new ones) and > can this data be used in the headers, or will be sitemap need a > tag? The internal cache will work more or less like C1's but with a few differences: 1) sitemap components will use the Modificable interface from Avalon to signal their behavior and allow the cache to provide caching for dynamic resources as well 2) sitemap components have direct access to the HTTP headers so they can provide fine-tuned caching capabilities without having to access any cocoon internal but I agree that it should be easier to integrate the two things since they are (even if loosely) connected. The XSP 1.1 specification will have a built-in caching behavior that will take care of both internal and external caching... any proposal in this sense is welcome. About the , I don't think the sitemap owns this concern... but I'm not sure... what do you guys think about this? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. Friedrich Nietzsche -------------------------------------------------------------------- Missed us in Orlando? Make it up with ApacheCON Europe in London! ------------------------- http://ApacheCon.Com ---------------------