You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/12/16 17:43:25 UTC
Usage of Sequence numbers to manage AP updates
Hi,
in a recent mail, I suggested we add some Timestamp to APs and Entries
to manage a differed evaluation of references to Subentries.
First, let's use the term 'SeqNumber' instead of 'Timestamp', as we
don't need such a value to be time based.
So far, it seems to be a valid idea, except that we won't be able to use
only one SeqNumber for all the AP types : we need one per role.
The rational is that SAP are exclusive, but only withing their roles.
What that means is that when you have two SAPs with the same role in a
tree, any entry below the lower SAP will only depends on this lower SAP,
not the other one. But if the entry is below two different SAPs, and if
we update the upper SAP, we have to know that this upper SAP has been
updated when processing the entry. With only one SeqNumber, that won't work.
So we need 4 SeqNumbers, to manage the AccessControl,
CollectiveAttribute, TriggerExecution and SubSchema roles.
It's not really a big deal, as all those seqNumber will be updated only
once per entry.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Usage of Sequence numbers to manage AP updates
Posted by Kiran Ayyagari <ka...@apache.org>.
On Fri, Dec 17, 2010 at 2:26 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 12/16/10 8:44 PM, Kiran Ayyagari wrote:
>>
>> On Thu, Dec 16, 2010 at 6:43 PM, Emmanuel Lecharny<el...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>> <snip/>
>>> So we need 4 SeqNumbers, to manage the AccessControl,
>>> CollectiveAttribute,
>>> TriggerExecution and SubSchema roles.
>>>
>>> It's not really a big deal, as all those seqNumber will be updated only
>>> once
>>> per entry.
>>
>> can we use a bit string with 128 bits, so that it can be represented
>> as a single ATAV
>> or is it gonna be a overhead?
>
> We can. I was actually thinking about using a list of long instead, but
> frankly, I think it's easier to have 4 different ATs : when we will havz to
> debug the stuff, trust me, being able to track the AccessControlSeqNumber
> evolution only, it will be way easier than finding this value inside a 128
> bits long BitString...
>
agree on the debugging view, how about having a helper class which we
can use for
this debugging purpose (like the kerberos's TicketFlags class), note
that this is just an idea,
need not be exactly the same, your call as you know the best thing
that works in this complex AP
solution :)
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
Re: Usage of Sequence numbers to manage AP updates
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 12/16/10 8:44 PM, Kiran Ayyagari wrote:
> On Thu, Dec 16, 2010 at 6:43 PM, Emmanuel Lecharny<el...@gmail.com> wrote:
>> Hi,
>> <snip/>
>> So we need 4 SeqNumbers, to manage the AccessControl, CollectiveAttribute,
>> TriggerExecution and SubSchema roles.
>>
>> It's not really a big deal, as all those seqNumber will be updated only once
>> per entry.
> can we use a bit string with 128 bits, so that it can be represented
> as a single ATAV
> or is it gonna be a overhead?
We can. I was actually thinking about using a list of long instead, but
frankly, I think it's easier to have 4 different ATs : when we will havz
to debug the stuff, trust me, being able to track the
AccessControlSeqNumber evolution only, it will be way easier than
finding this value inside a 128 bits long BitString...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Usage of Sequence numbers to manage AP updates
Posted by Kiran Ayyagari <ka...@apache.org>.
On Thu, Dec 16, 2010 at 6:43 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi,
>
> in a recent mail, I suggested we add some Timestamp to APs and Entries to
> manage a differed evaluation of references to Subentries.
>
> First, let's use the term 'SeqNumber' instead of 'Timestamp', as we don't
> need such a value to be time based.
>
> So far, it seems to be a valid idea, except that we won't be able to use
> only one SeqNumber for all the AP types : we need one per role.
> The rational is that SAP are exclusive, but only withing their roles. What
> that means is that when you have two SAPs with the same role in a tree, any
> entry below the lower SAP will only depends on this lower SAP, not the other
> one. But if the entry is below two different SAPs, and if we update the
> upper SAP, we have to know that this upper SAP has been updated when
> processing the entry. With only one SeqNumber, that won't work.
>
> So we need 4 SeqNumbers, to manage the AccessControl, CollectiveAttribute,
> TriggerExecution and SubSchema roles.
>
> It's not really a big deal, as all those seqNumber will be updated only once
> per entry.
can we use a bit string with 128 bits, so that it can be represented
as a single ATAV
or is it gonna be a overhead?
--
Kiran Ayyagari