Fwiw: I think it's a good idea to give apps more control over the events they are interested in (e.g. With the approach you suggest) Common example would be apps interested in changes to nodes only if a specific property has a specific value, e.g. sling:resourceType
Sent from a mobile device On Wed, Sep 7, 2016 at 3:51 PM +0200, "Stefan Egli" <[email protected]<mailto:[email protected]>> wrote: I moved the discussion to the jackrabbit list. Cheers, Stefan -- http://jackrabbit.markmail.org/thread/xm2xa77g2rzxxuly On 07/09/16 15:04, "Michael Dürig" <[email protected]> wrote: > >On 7.9.16 2:27 , Stefan Egli wrote: >> Hi Michael, >> >> Were you thinking to open those classes to the outside or to add more >> options to the filter that would translate to other filter-Conditions? > >No not open them. But make their functionality available through an API. >Since JCR is dead (hint hint) we probably have to come up with an ad-hoc >API here. > >Michael > >> >> I was thinking of leaving absPaths/excludedPaths/isDeep as is, but >> additionally have that suggested Filter interface that would be applied >> afterwards to further filter. I think having these base paths in the >> filter are very useful so we could just build on top of those. >> >> Cheers, >> Stefan >> >> On 07/09/16 14:16, "Michael Dürig" <[email protected]> wrote: >> >>> >>> Hi, >>> >>> On several occasions I suggested to work on a way to expose the >>> flexibility of event filtering exposed by the classes in >>> org.apache.jackrabbit.oak.plugins.observation.filter through an API. >>> E.g. such that Sling could use more filtering mechanisms from Oak >>> instead of filtering events after the fact. But such efforts so far >>> didn't go anywhere. >>> >>> In that sense +1 for trying again ;-) >>> >>> Michael >>> >>> On 7.9.16 2:09 , Stefan Egli wrote: >>>> Hi, >>>> >>>> 1) Looking at typical use case patterns of the JackrabbitEventFilter >>>> (used >>>> with EventListeners) it seems like the filtering options that it >>>> provides >>>> (ie absPaths, excludedPaths, isDeep) could be generalized and made >>>>more >>>> flexible, eg via a Filter that could look like something along the >>>> following >>>> lines: >>>> >>>> public interface Filter { >>>> >>>> >>>> >>>> enum FilterResult { >>>> >>>> INCLUDE, INCLUDE_SKIP_CHILDREN, >>>> >>>> EXCLUDE, EXCLUDE_SKIP_CHILDREN }; >>>> >>>> >>>> >>>> FilterResult filter(String nodeOrPropertyPath); >>>> >>>> } >>>> >>>> >>>> The goal would be that listeners themselves could do arbitrary complex >>>> filtering instead of being restricted by absPath,excludedPaths,isDeep. >>>> With >>>> the goal that the number of events that are generated could be reduced >>>> as >>>> much as possible (helps keeping the number of observation events in >>>> queues >>>> small). >>>> >>>> 2) It also looks like sometimes listeners aren't really interested in >>>> the >>>> event details but just in the fact that something changed. That could >>>>be >>>> indicated to oak by something like >>>> >>>> boolean ignoresEventInfo; >>>> >>>> >>>> .. which could be used to throw away CommitInfos. >>>> >>>> Has this been discussed before and/or what's your opinion on this? >>>> >>>> Cheers, >>>> Stefan >>>> >>>> >>>> >> >>
