On 07.11.2013, at 10:44, Jukka Zitting <[email protected]> wrote:
> Right, but the local-only observation pattern is structurally flawed, > as it can't guarantee that the events actually do get processed (for > example if the server dies during event delivery). Observation can't guarantee everything, at some point the application needs to handle that, e.g. manual refresh option or users simply repeating the task. And I thought we agreed on removing those nasty cluster events as much as possible :) IMHO this is a place to trade off 100% availability for scalability. > Commit hooks don't have that problem. Switching code to commit hooks and making them very Oak dependent is quite an effort, if that's what you mean. Or do you suggest to implement some similar simple listener mechanism based on commit hooks (but not forcing applications to write them themselves, coding against the oak internal API within the listener)? As mentioned, ideally that new API I propose can be hooked into the existing JCR API with just an additional listener subtype interface (say in jackrabbit-api) and could be implemented transparently for Jackrabbit 2 (well, with some utility). Since we say the long-running session is no issue at all, we don't need a completely separate API to manage that. > AFAICT there's no use case for which the local only -listener pattern > would be the best solution, so while we do need it for backwards > compatibility, it IMHO should not be the default for any new > functionality. >From an application perspective, I see it completely opposite :) Cluster >events mostly only apple to core infrastructure (e.g. the code deployment in >Sling), but not the high-level content processing for which observation is >great. Those are local by default and are usually the majority, at least in >our CMS environment. Cheers, Alex
