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 meant less work to develop - you're right that forced pipeline caching based on an expires parameter might be less work for the user. See my email to Miles with my concern though about only fitting one of the three broad cache invalidation schemes which I think Cocoon should support.
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.
Hmm. I'll have to go back and look at that more carefully.
Geoff
