On Feb 19, 2008 6:14 AM, Emmanuel Lecharny <email@example.com> wrote:
I don't think that upDn is usefull.
You mean in the context of [de]serializing?
That means :
- define some DN serializer/deserialize (done)
- define DN comparators (almost done)
- modify the JdbmIndex API to be able to pass keySerializer and
The last point is the missing part of the task.
Note : why is upDn index useless ? Because if we store a serialized
LdapDN, then we have access to the UP form, and more than that, w will
always work with normalized forms of DN,
Not always true. Sometimes we have use the user-provided (UP) form of a DN but very rarely. Also the LdapDN is an atrocity when it comes to manageability. We may break it up in the future and break it apart so it does not contain both UP and normalized forms. This is causing issues for us as an API when users don't know what kind of DN they're dealing with.
You are right though that some things about UP DN in the server definitely need to change. I just don't want anyone (including me) to touch anything associated with it until we have a clear idea of the end state of DN normalization.
I don't want to be in constant flux refactoring this server.
returning the UP form only when
building the respons, which is easy, as we store the UP form into the
seralized DN. This will also benefit to the Add request, as we won't
have to uodate 2 index instead of one...
I worry that now we're going to store both the UP and normalized DN. Perhaps this is better since disk is cheap and the normalization computation is costing us. However we talked about making this configurable at some point: can we still do that?