The direct consequence is that anytime we add an ACI which span over a
lot of entries, we wwill have a large number of modifications applied,
and it's definitively a costly operation (moreover, I don't see how we
can assure the atomicity of such an operation...)

This is one of the reasons we still don't have proper subentry support in OpenLDAP. I think to do it in a sane fashion you want all of these XXXsubEntry attributes to be generated dynamically. But, if you have a lot of subentry specifications applying to a tree, you'll pay for it in search performance because you have to evaluate all of them each time you reference an entry. That leaves the caching approach that we took for subtree rename.

I'm not sure that, due to the complexity of subtree definition, we will have 'a lot' >> a few tens of subtrees...

In this case, the cost of generating those attributeTypes dynamically can be mitigated.

Of course you will always find pathological admins defining hundreds or even thousands of subtrees (I have in mind some tools which would automatically generates those guys, ot a huan being, but you never know ;), but in this case, well, I woud ask them to switch to OpenLdap ;)

More seriously, checking in an entry found during a search is a part of some subtree is just adding one filter and as it will be executed in emory, it should not overload the server. The time penalty to process this information is obvious, but we can bear with it. We are not talking about order of magnitude here, not even a 2 times factor, it should be some extra percentage.

Anyway, I can't give numbers right now as we first have to get the subtree creation handled correctly first. The current implementation works, but it's obviously more a proof of concept than a realistic iplemntation.

Thanks Howard !

 -- Howard Chu
 CTO, Symas Corp. 
 Director, Highland Sun
 Chief Architect, OpenLDAP

Emmanuel Lécharny