I have been having a good look around the caching code, and have found that, by default, with the EventCache block enabled, Cocoon uses the EventCache code.
Given that the code is marked unstable, wouldn't it make sense for the default configuration of Cocoon use CacheImpl instead of EventAwareCacheImpl?
While I'm fine with your proposal, I should note that the _code_ isn't really unstable -- the API was definitely but is less so now. I have been thinking of removing the draconian warnings from the javadoc and simply leaving the gump descriptor marked "unstable" since this is new
conceptually and probably isn't used in any live deployments yet.
When enabled, the EventAwareCacheImpl merely looks at each SourceValidity in a pipeline on its way into the cache and does nothing else if you aren't using any EventValidities. This results in a net cost of about 3-10 calls to instanceof, which in my tests was a total of 0-10ms (less than the resolution of the JVM IIUC, so hard to know what exactly). I judged that this wasn't doing any harm, and even thought about whether it should just go in core (saw no reason for it, but just to give perspective).
It seems to me that this block is somewhat different from many others. Disabling Linotype or not because it is unstable won't affect the basic running of your Cocoon setup. However, the EventCache is directly overriding something central to a Cocoon system, i.e. its cache, with code marked unstable. This doesn't seem ideal to me.
True that this is different than others - I'm fine to mark it excluded by default if there's still a level of concern.
Best immediate solution to my mind is to mark EventCache block as excluded by default in blocks.properties. Other solutions are likely to be a lot more complicated.
[Geoff - nothing against your code! I have ideas where I might want to use it myself, just going on your own labelling of the code as unstable!]
No offense taken at all - in fact very glad to hear you're thinking of trying it out as me, Unico and Peter H. are probably the only three that have looked at it much. I'd love to hear any ideas you have for improvement or just to have you start hacking at it directly.
Geoff
