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
