directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: AP's data structure
Date Mon, 27 Dec 2010 13:17:05 GMT
On 12/27/10 1:49 PM, Kiran Ayyagari wrote:
> On Mon, Dec 27, 2010 at 4:35 PM, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>> Hi,
>>
>> here is a description of the data structure used to handle the
>> Administrative model in the AP branch.
>>
>> We manipulate two kinds of objects that need to be stored in memory when the
>> server is started :
>> - administrativePoints (APs)
>> - subentries (SEs)
>>
>> The relation between those two elements are simple :
>> - an AP can have zero to many SEs
>> - a SE can cover one to many APs role, but only one AP entry
>> - APs and SEs both have roles : AccessControl (AC), CollectiveAttribute
>> (CA), TriggeExecution (TE) and SubSchema (SS)
>> - roles are defined by some auxiliary ObjectClass in SEs, by an attribute
>> (AdministrativeRole) in APs
>> - the relation between an AP and a SE exists only if they have the same
>> role.
>> - A SE *must* be declared under an AP, which means that we can't have an
>> isolated AP, when the AP can be defined alone, but in this case, it's just a
>> placeholder.
>>
>> As an example, if we define an AP for 2 roles (AC and CA), and three
>> subentries : SE1 for CA, and SE2 for AC and CA (the two subentries define
>> two different areas with their respective subtreeSpecification), the SE1 is
>> associated with the AP entry and with the CA role, and SE2 is associated
>> with the same AP entry but covers 2 roles.
>> Here, an AP entry is associated with 2 SEs, and SEs can cover one to many
>> roles.
>>
>> To handle this, we need to define the following structures :
>> - AdministrativePoint will describe a AP role. It will be loaded when the
>> server is started, and loaded into some caches : one cache per role. As we
>> can't have 2 APs with the same role at one level in the DIT, we can safely
>> store the cache in a DnNode<AdministrativePoint>  structure. The
>> AdministrativePoint itself is an interface, with some extented classes :
>>
>> (AdministrativePoint)
>>     o
>>     |
>>     +-- [AbstractAdministrativePoint] (A)
>>           ^
>>           |
>>           +-- [AutonomousAdministrativePoint]
>>           |
>>           +-- [AccessControlAdministrativePoint](A)
>>           |     ^
>>           |     |
>>           |     +-- AccessControlAAP
>>           |     |
>>           |     +-- AccessControlIAP
>>           |     |
>>           |     +-- AccessControlSAP
>>           |
>>           +-- [CollectiveAttributeAdministrativePoint](A)
>>           |     ^
>>           |     |
>>           |     +-- CollectiveAttributeAAP
>>           |     |
>>           |     +-- CollectiveAttributeIAP
>>           |     |
>>           |     +-- CollectiveAttributeSAP
>>           |
>>           +-- [TriggerExecutionAdministrativePoint](A)
>>           |     ^
>>           |     |
>>           |     +-- TriggerExecutionAAP
>>           |     |
>>           |     +-- TriggerExecutionIAP
>>           |     |
>>           |     +-- TriggerExecutionSAP
>>           |
>>           +-- [SubSchemaAdministrativePoint](A)
>>                 ^
>>                 |
>>                 +-- SubSchemaAAP
>>                 |
>>                 +-- SubSchemaSAP
>>
>> As we can see, we have as many classes as we have roles, and covered area.
>> (At this point, I'm not sure we need to define the AAP classes for each
>> role).
>> The abstract class holds all the fields needed to manipulate the APs (except
>> for the AAP) :
>> - DN dn : the AP position in the DIT
> if possible we should avoid using DN altogether in these data
> structures, as we already know
> updating these DNs is expensive
Yeah, it might be possible to get rid of DN in the AP class. We never 
access the AP directly, we use the DN for that, so we already have the 
DN, no need to store it.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message