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 another property for that.
Makes sense
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 precise
>>
>> I plan t
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 API early this week :) S
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 t
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 cal
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 (basica
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 t
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 most expensive one at t
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
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 expo
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 Ziegele
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 implementation can optim
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 it would be useful for
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 cha
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
15 matches
Mail list logo
