directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject About AP internal structure
Date Fri, 24 Sep 2010 14:13:49 GMT
  Hi guys,

defining the right data structure to manage APs is a major burden. It's 
now the third version I'm designing, and I think at least we may have 
the correct one. Let me expose what I'm coming from, something we 
discussed with Pierre-Arnaud a few minutes ago.

Right now, to manage APs, we are using a DnNode<AP> data structure. 
Basically, it mimics the DIT structure (each node has a RDN, and some of 
the nodes have APs). You can add a new AP into this tree, by doing a 
dnNode.add( DN, AP ) (this DnNode data structure is also used to manage 

That's fine, as soon as you don't want to manage AP removals from this 
tree, as AP have strong relationships :
- an IAP must have a parent SAP with the same role or a parent AAP
- you can't have an IAP and a SAP with the same role in a node
- when a node contains an AAP, no other AP can be added.
- a node can't have twice the same IAP/SAP

Of course, removing a node must keep the tree consistent, wrt those four 

How easy is it to handle the addition/removal from such a data structure 
? Short answer : very tough. When you remove an AP from the middle of 
the tree, you have to check for all the underlying APs that they respect 
the four rules.

 From our convo, we do think that handling 4 different trees would be 
easier (one per type of role : AccessControl, CollectiveAttribute, 
TriggerExecution and Subschema).

As an AAP covers the four different types, if we have a tree for each of 
them, we simply have to do the check n each of those trees, without 
having to deal with the specific cases.

 From the performance POV, it should be equivalent. From teh ease of use 
POV, it would be way better. For instance, the AccessControl Interceptor 
just deal with the AceessControl AP tree, and does not care about the 
three others.

I think this is the way I'm going to go, if no one has a better idea.

Thanks !

Emmanuel L├ęcharny

View raw message