Oak would be collecting the name of the properties (OAK-4907) which
got changed in a given commit and that can be used for filtering. This
I think should help the MapEntries case and probably the resourceType
case also. They can just hint for those property names and then
listener would only be called if there is some change in those
properties

> I would rather go with a "property names filter hint" - and if we detect
other use cases we add another property for that.

Makes sense. This would keep things simple and precise

> Yes, and as mentioned a check based on a resource type is not that easy,

Can you provide some details on what kind of change the impl is
interested in. Is it change in the value of resourceType property? Any
pseudo code of the kind of logic that listener would be performing.
That would help in determining if we can make this case faster

Chetan Mehrotra


On Sat, Oct 15, 2016 at 7:51 PM, Carsten Ziegeler <cziege...@apache.org> wrote:
> Dominik Süß wrote
>> For me one of the most interesting filters for "native" filtering would be
>> based on ResourceType (& RT changes). Optimally we would even have the
>> option to filter by ResourceType and its SubTypes - but detecting the
>> subtypes is something that would go beyond a hint (basically preprocessing
>> a hint to "unfold" it into all of the subtypes to watch out for).
>>
>> I guess within the ResourceTypes the best practice would go into the
>> direction of SubTyping whenever the group covered is too generic and needs
>> to be treated differently.
>>
> Yes, and as mentioned a check based on a resource type is not that easy,
> you need to check the resource type property, the super type property,
> maybe the jcr primary node type and then also walk up the resource type
> hierarchy.
> If Oak would provide a hook for registering these additional checks then
> we "maybe" could do it.
>
> Carsten
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Reply via email to