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
