> On 21.9.16 8:13 , Carsten Ziegeler wrote:
>> Finally, recently some people suggested that we support all of Oaks
>> filtering possibilities for the ResourceChangeListener. I'm not a fan of
>> that - first of all, we should only support what is really needed.
>> Second, as soon as we support it, it means that every resource provider
>> needs to support it which might but a high burden for nothing on the
>> implementations. And finally, as we already see with the globbing,
>> filtering is nice but we have to be careful for remove events and
>> clearly specifiy how this works - and specify it in a way that it really
>> works for the listeners.
> Not so recently actually: http://markmail.org/message/zmwhp7a7tshtfvob
Well, it has been added to Sling recently :)
> I don't think you have to support all of Oak's filtering possibilities.
> You can still just use the ones you need. Mind you that Oak also has
> support for glob filters.
Sure, that's what we do.
> Pushing filters as much into Oak has many performance advantages though
> compared to filter messages after delivery. Also Oak would easily able
> to support the delete use case described above.
In all cases, always, guaranteed?
But we have to think about other providers as well, what if I use the
mongo resource provider? Can we make the same guarantees? We have an
abstraction and have to come up with a solution that always works
Adobe Research Switzerland