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