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.
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) 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. WDYT? Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
