looks fine to me
>-----Original Message----- >From: Carsten Ziegeler [mailto:[email protected]] >Sent: Monday, May 18, 2015 8:17 AM >To: Sling Developers >Subject: [RT] New Observation Support > >Right now, resources changes are propagated through event admin - which >at the time sounded like a good idea. Over time, this has shown to be a >bottle neck. >Basically there are at least three problems: >- the sender of the resource events does not know whether there is a >receiver, therefore events for each and every change need to be sent >- event objects are immutable and therefore all relevant data needs to >be calculated upfront, even if it's not used. For example a resource >event contains the resource type which needs to be fetched from the >repository, even if no one is interested in it. >- receivers of the events can't easily act on behalf of the user who >initiated the change. > >I created a new listener api at [1] which defines a ResourceListener >interface and some ways how to specify the events one is interested in. >The user aware resource listener allows to act on behalf of the user (if >that information is available). > >On the other side, a new service, the ObservationReporter [2] is >defined. Resource providers report changes through this interface. The >payload of such an event is an interface which allows for lazy retrieval >of the information. > >We can also use this mechanism for compatibility and an implementation >of the observation reporter might sent all events via the event admin. > >[1] >https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api- >v3/src/main/java/org/apache/sling/api/resource/observation/ >[2] >https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/api- >v3/src/main/java/org/apache/sling/api/resource/provider/ObservationReporter.ja >va > >Regards >Carsten >-- >Carsten Ziegeler >Adobe Research Switzerland >[email protected]
