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 >>>> >>>> >>>> >> >>
