On Wednesday 04 November 2015 18:45:00 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. > > 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.
One event per resource makes implementing depending systems more straightforward, e.g. adding/removing data for a resource from a search index. So +1. > 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. What does that mean? _too_ many for whom? Can we process _too_ many events reliable? > 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? hm, added/removed resources and added/removed resource providers are from some aspects totally different use cases which I think should be seen as such. I would like to differ between added/removed resources and added/removed resource providers. But having events for all resources added/removed when a resource provider is added/removed is also helpful. -1 for collapsing. How rich are these events? Can a listener determine the provider for a resource? Can a listener determine if a resource was added/removed because its provider was added/removed? - forgive my ignorance, hadn't time to look into the new APIs so far. Regards, O. > Regards > Carsten
