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
