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
partitions)
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
rules.
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 !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
