cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: forced caching of volatile data
Date Wed, 27 Aug 2003 02:11:08 GMT
Gianugo,

Sorry for the long delay.  Mini-vacation and only had this email at home
(pop3 here set to remove from server...)

Gianugo Rabellino wrote:
> Geoff Howard wrote:
> 
>> I apologize if I've already mentioned this, but I think there are some 
>> different angles on solving your problem which you may want to consider.
>>
>> One is implemented in part in the event-cache block but it could be 
>> generalized to work for any component.  Unico Hommes wrote a Generator 
>> (in that block, but don't know its name) which uses a Delegation 
>> pattern to wrap any other arbitrary Generator.  It delegates all 
>> interface methods to the wrapped generator except for the get Validity 
>> (and currently the key as well, but I think that might need to 
>> change.  He then uses a factory which specifies how to construct the 
>> overridden validity.  The plan was to generalize this to work with any 
>> component. Hope that makes sense.
> 
> Interesting and worth a look, but I see a few problems:
> 
> 1. Usability wise it might be uncomfortable for users to wrap every non 
> cacheable sitemap component into a delegate (provided that users know 
> what is cacheable and what is not);

True.  I think the majority of cases could be covered by a few 
pre-configured components though which may mitigate this.

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

> 3. AFAIU, in order to use the delegate components, you should be using 
> the EventAwareCacheImpl, am I wrong? This might be a serious showstopper.

Only as it is now.  I meant to convey that the same technique might have 
more general use and could be refactored with that in mind.

> The whole idea of this expires-enabled stuff is that of a simple 
> solution for a simple scenario where the user knows in advance for how 
> long a pipeline might be valid. A sitemap parameter, and you are ready 
> to go, just as httpd's mod_expires does ... I'm not sure that the 
> delegate solution is understandable by a non java programmer: it 
> requires quite a bit of understanding of how the event cache works and a 
> good knowledge of Cocoon internals, don't you think so?

Well, with the EventAware code two factories are defined by default and 
the same would make sense in the more general case.  In the end, for the 
most common use case (exactly what you've described) it'd be simply a 
matter of changing the map:transform type=xxx and a few parameters. 
Most users in your case would need the same modifications, and they 
would be pretty easy to configure.

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.

>> 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.  Code duplication could be 
problem because of the different pipeline implementations already in 
place if some (as I think might be the case) some orthogonal 
relationships occur.

>> A third is to consider the event based cache stuff itself.
> 
> Which looks really cool, and definitely it's something to work on, apart 
> from the Expires stuff. How much do you still consider it alpha stuff?

Ooh.  I meant to remove all my dire warnings from the source files - 
working on that now.  They were only meant to be there because I 
comitted a first draft that I planned on refactoring but wanted the 
original in cvs for collaboration with a few people who showed some 
interest.

I'd still say the block should be alpha since to my knowledge no one is 
using it.  But I'd consider the API (which is really only a few simple 
interfaces) stable.  I have only two outstanding issues I'm investigating:

1) Using TransientStore to persist the state of the event-key mappings. 
  I have this 90% on my harddrive and will keep plunking 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.

Geoff


Mime
View raw message