>From the use cases I know, the listeners register for a specific path and are rarely interested in anything else. Some do check the resource type as well. For example the script engines check for changes under /libs and /apps (the resource paths actually) for changes to scripts, the job engine checks for new jobs somewhere under /var/jobs and checks the resource type as well etc. Many use cases check for changes (resource added, resource removed, resource changed) and then re-read the sub tree based on the changes.
The mapping handler in the resource resolver is probably the most interesting one as it changes for nodes with some well defined properties, basically scanning the whole repository. And I think the i18n stuff does something similar (but this one might still be using jcr observation). This list is by no means exhaustive for Sling, but we see that we already have two listeners scanning the whole repository and require access to properties. Carsten 2013/10/22 Dominik Süß <[email protected]> > In a discussion [0] within the Oak mailinglist it became clear that the way > Sling listens zu JCR Repository Changes and transforms all of them to > events will not scale well in some big scale scenarios that oak is aiming > to enable. Therefore the question was posted if it would be feasible and/or > even necessary to refactor the API and deprecate (or at least discurrage) > registration in a global scope as currently done. > > Since I do not want to copy & paste parts of the discussion I do hope that > the participants of the oak discussion add the remaining options with some > more detail about consequences than can be found in the linked discussion. > > It would be great to also get some feedbacks of consumers of the existing > API about the usage to identify how finegrained a potential > registrationlogic with paths/properties might need to be. > > Best regards > Dominik > > [0] http://markmail.org/message/n5vllhjoawypteck > -- Carsten Ziegeler [email protected]
