Re: What all changes does ResourceChangeListener are interested in

2016-10-17 Thread Stefan Egli
On 17/10/16 09:38, "Carsten Ziegeler" wrote: >Chetan Mehrotra wrote >> On Mon, Oct 17, 2016 at 11:04 AM, Carsten Ziegeler >> wrote: > I would rather go with a "property names filter hint" - and if we >detect other use cases we add

Re: What all changes does ResourceChangeListener are interested in

2016-10-17 Thread Carsten Ziegeler
Chetan Mehrotra wrote > On Mon, Oct 17, 2016 at 11:04 AM, Carsten Ziegeler > wrote: >>> 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

Re: What all changes does ResourceChangeListener are interested in

2016-10-17 Thread Chetan Mehrotra
On Mon, Oct 17, 2016 at 11:04 AM, Carsten Ziegeler wrote: >> >>> 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 > > I plan to release

Re: What all changes does ResourceChangeListener are interested in

2016-10-16 Thread Carsten Ziegeler
Chetan Mehrotra wrote > 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

Re: What all changes does ResourceChangeListener are interested in

2016-10-16 Thread Chetan Mehrotra
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

Re: What all changes does ResourceChangeListener are interested in

2016-10-15 Thread Carsten Ziegeler
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

Re: What all changes does ResourceChangeListener are interested in

2016-10-15 Thread Dominik Süß
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

Re: What all changes does ResourceChangeListener are interested in

2016-10-15 Thread Carsten Ziegeler
Chetan Mehrotra wrote > On Thu, Oct 13, 2016 at 6:18 PM, Carsten Ziegeler > wrote: >> The listeners we have are really just interested in paths > > Path is one aspect. There must be other aspect like change in specific > property name like sling:alias etc. > I think the

Re: What all changes does ResourceChangeListener are interested in

2016-10-13 Thread Chetan Mehrotra
On Thu, Oct 13, 2016 at 6:18 PM, Carsten Ziegeler wrote: > The listeners we have are really just interested in paths Path is one aspect. There must be other aspect like change in specific property name like sling:alias etc. Chetan Mehrotra

Re: What all changes does ResourceChangeListener are interested in

2016-10-13 Thread Carsten Ziegeler
Chetan Mehrotra wrote > Sure. So can you provide some details on what all the listeners are > interested in. The listeners we have are really just interested in paths, in Sling so far we don't have any special needs I think :) Carsten > > We can then decide what type of filtering we should

Re: What all changes does ResourceChangeListener are interested in

2016-10-13 Thread Chetan Mehrotra
Sure. So can you provide some details on what all the listeners are interested in. We can then decide what type of filtering we should expose. At simplest level it can be just a ldap filter like string as used in service filtering. Chetan Mehrotra On Thu, Oct 13, 2016 at 5:01 PM, Carsten

Re: What all changes does ResourceChangeListener are interested in

2016-10-13 Thread Carsten Ziegeler
Chetan Mehrotra wrote > On Thu, Oct 13, 2016 at 2:53 PM, Carsten Ziegeler > wrote: >> For now, we limit the functionality as we have to support every feature >> across all resource providers. > > Okie. But may be we can add support for filtering hint. If the > underlying

Re: What all changes does ResourceChangeListener are interested in

2016-10-13 Thread Chetan Mehrotra
On Thu, Oct 13, 2016 at 2:53 PM, Carsten Ziegeler wrote: > For now, we limit the functionality as we have to support every feature > across all resource providers. Okie. But may be we can add support for filtering hint. If the underlying implementation can optimize for that

Re: What all changes does ResourceChangeListener are interested in

2016-10-13 Thread Carsten Ziegeler
Chetan Mehrotra wrote > Hi Team, > > As part of OAK-4796 the observation handling is being improved. Focus > here is to make use of pre filtering to avoid expensive diff operation > depending on what all changes the listener is interested in. > > So if listener can tell Oak precisely what all

What all changes does ResourceChangeListener are interested in

2016-10-13 Thread Chetan Mehrotra
Hi Team, As part of OAK-4796 the observation handling is being improved. Focus here is to make use of pre filtering to avoid expensive diff operation depending on what all changes the listener is interested in. So if listener can tell Oak precisely what all changes it is interested in (filtering