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 16:47:42 UTC

AP management, heads up

Hi guys,

so I created a branch to play with the AP management, using a "eval and 
store" algorithme (ie we don't update all the entries when we update an 
AP, we do it on the fly and we store the evaluation to avoid doing it 
again for the next read.)

I started experimenting, but the code is quite complex, so I decided 
that we need to stop and describe on 'paper' what kind of impact such an 
implementation can have.

I will post soon the result of this analyse. It will be a _long_ mail, 
as I have evaluated all the operations one by one, trying not to forget 
any use case.

So far, what I can tell is that there is _no_ difference between an 
"Immediate update" and a "Eval and store" algorithm, as a differed 
evaluation can ends as an immediate update if we do a full search just 
after having updated an AP. What I think is that once the "eval and 
store" algorithm will be implemented, it will be *very* easy to 
implement an "immediate update" algorithm, and I think it should be an 
option in the server (some admin would hate paying the price of such on 
the fly evaluation, when they can run the update at 4am)

Another important point is that X.500 implies that an AP or a Subentry 
are standard entries, and as such can also be managed by the 
administrative model. I think it would be way more complicated to 
implement atm, and I'd like to suggest that APs and Subentry can only be 
modified by the server admin, and no one else.

So expect a long mail soon, and I'd like you to review it to be sure I'm 
not missing too many use cases.

Also keep in mind that the current server implementation works, but does 
not support many aspects of the X.500 administrative model :
- IAP are not supported, so there is no way to define cumulative 
SubtreeSpecifications
- I'm not sure we support more than one subentry per AP for a given role
- We currently have 7 JIRA directly related to problems with the way we 
handle APs

Ok, that's it. More to come soon...

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com