Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F4C63F9.50105@apache.org>
Date: Wed, 27 Aug 2003 09:55:37 +0200
From: Gianugo Rabellino <gianugo@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: forced caching of volatile data
References: <20030811012530.373a7bfa.ruf10@op.pl>
 <3F373A3B.5885.177883E@localhost> <3F3737B6.6090108@pcextremist.com>
 <3F37921D.2060406@leverageweb.com> <3F3816B4.2020909@pcextremist.com>
 <3F38A248.5010607@apache.org> <3F3A870B.5020202@pcextremist.com>
 <3F43B68C.8010301@apache.org> <3F43C654.1080308@leverageweb.com>
 <3F43E5F4.5010808@apache.org> <3F4C133C.1050200@leverageweb.com>
In-Reply-To: <3F4C133C.1050200@leverageweb.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Geoff Howard wrote:


>> 2. There is no transformer yet (even if, agreed, it would be pretty 
>> easy to build one);
> 
> True, but that seemed quite a bit less work than the solutions you have 
> been looking at.  (though I was only following the discussion casually)

Not really, since it would be transparent to the user. With your 
solution the user would have to configure delegates for every non 
cacheable components.

> I think of expires as solely in the realm of external to cocoon caches 
> (browser, or proxy) which is why proposing a cocoon-cache centered 
> solution seemed right to me.

This is not the case actually. Expires are used internally too, since 
internally the cache implementation has this information available, so 
that : the Cocoon cache will serve a resource from the cache using the 
expires algorithm even to internal cocoon requests.

>>> The second possibly simpler solution is to create a new pipeline 
>>> implementation that always caches.  So, when you have a pipeline that 
>>> should be forced to cache, you segregate it into its own map:pipeline 
>>> section with a parameter that speficies how long to cache.
>>
>>
>> Yes and no. We have been through this before, but again there is both 
>> a backward incompatibilty to consider (the current 
>> CachingProcessingPipeline supports Expires) and a fair amount of code 
>> duplication needed between the two implementations. But again, it's 
>> something to consider.
> 
> It supports an expires header going to the client, not a SourceValidity 
> object with an expire (invalid) timestamp.

Not really. As I said above, the expires information is kept internally 
too. It's not a SourceValidity object but an attribute of cache entries, 
which is checked by the pipeline to decide whether to go through each 
SourceValidity object or just serve it right away.

> 2) Investigate the feasibility of wildcard matches on events (and 
> whether they're even necessary).  Some implementation ideas could 
> possibly require additions to the interfaces, but I'd want to plan those 
> in backwards compatible ways even though the alpha block status may not 
> require it.
> 
> The examples that have come up for this by the way are file system 
> events and date/time based events.  Both of these can be handled in 
> other ways so they may not be necessary at all (why I've ignored them 
> for now).  If a directory structure is used for validity (say 
> /opt/foo/bar/) and you want to signal that all of /opt/foo/ has been 
> updated you'd want to do something like /opt/foo/* but the current 
> implementation might not deal with this well.

This looks very interesting indeed. I'll for sure give it a run. :-)

Ciao,

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Now blogging at: http://blogs.cocoondev.org/gianugo/)