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 - 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 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? Robert
