Am 04.11.15 um 19:27 schrieb Robert Munteanu: > On Wed, 2015-11-04 at 18:45 +0100, Carsten Ziegeler wrote: >> The current active model for observation event for resources through >> OSGi events is modelled after JCR observation which means that for >> changes to a tree you might only get an event for the root of that >> tree. >> Especially when a whole tree is deleted, you get a single event. >> I assume, the same could in theory be true for adding. > > Just to make sure I understand correctly: > > - when a tree at /foo is deleted we get a single event which says that > the node at /foo is deleted, but we do not know which children were > removed - we only get a single path
Correct. > - when a tree at /bar is added, we get a single event but we get all > the date about the resources under /bar, e.g. /bar/one/two/three I think this depends :) Afaik, right now for adds we get an event for every resource, but this is not necessarily guaranteed by JCR observation (at least that's what people told me). > > Is that correct? > >> The question is, whether we want to keep this model for the >> observation >> API we're about to implement. Especially as there are some additional >> things to consider: >> >> 1. With Oak we could register observation listener which provide the >> information about every node removed/added/changed. So we can send >> out >> detailed events. Other resource provider implementations could simply >> follow that concept. >> >> 2. We have three events for resources: added/removed/changed but also >> two events for resource providers. Obviously, if a resource provider >> is >> mounted at some path and is unregistered, the whole tree is removed. >> Again, we just send out a single event. >> >> For 2. we definitely don't want to send out an event for every >> resource >> of that provider as that would be way too expensive. >> >> For 1. we might start sending out too many events as well and I >> assume >> code is already prepared for that case. >> >> I think we should keep the optimization (and make this clear in the >> new >> observation API) > > +1 > >> and we probably should collapse the two special >> resource provider events into resource events: instead of sending out >> a >> resource provider added/removed, we send out a resource >> added/removed. >> Listeners right now usually handle all five events, and we could >> reduce >> this to three events, making everything compacter, nicer and easier >> to >> understand. > > I think simplifying the listeners is good, but I wonder whether anyone > actually listens to the resource provider added/removed events. Perhaps > we can have a separate listener for those? Every implementation doing caching (e.g. jsp scripting) listens to those events. That's a must, otherwise you end up caching something from a provider which disappeared after you cached it. My initial idea was to have a separate interface, but as the usual pattern is to listen to both anyway, I think we can just fold the events in and make everything easier Regards Carsten > > Robert > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
