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
