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
