Alex Karasulu wrote:
On Feb 19, 2008 6:14 AM, Emmanuel Lecharny <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I don't think that upDn is usefull.
You mean in the context of [de]serializing?
In the server as a whole.
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.
You always have access to this form, if needed, as this is the DN basic
form (remember that DN are passed by incoming requests). So no need to
have an index on it.
Also the LdapDN is an atrocity when it comes to manageability.
Can you elaborate ?
We may break it up in the future and break it apart so it does not
contain both UP and normalized forms.
You may want to have a stripped form of the current LdapDN ( a 'client'
form), but in fact, you already have it : simply use LdapDN as is, and
you are done (you won't see any kind of normalized form unless you
explicitely ask for a normalization to be done). Maybe having a better
separation, like in ServerEntry and ClientEntry could be a good idea.
Also keep in mind that in the server, the DN is the most important
structure with the ServerEntry. It is also the most costly object to
manipulate, and it can kill the performances if not handled correctly.
This is causing issues for us as an API when users don't know what
kind of DN they're dealing with.
This is simply not true. What you call 'user' here is simply always
managing the UP form, nothing else. To get a normalized form, you must
be into the server, or at least, have access to the OID registry, and
explicitely call the normalize( OIDs ) method.
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.
We have to be consistent. The current situation is not good. We have
open issues because we don't know which form we have to use (normalized
or UP). For instance, the Principal.
So far, 99% of the DN are used normalized - as it should - inside the
server, and I'm not even sure we use the UP form in any case (so the 1%
may be patholological cases).
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...
wdyt ?
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?
The cost should be compensated by the normalizing gain. Here, there are
some key factors : size on disk and memory. If we have enough cache,
size is irrelevant. If we don't have enough cache, reading DN from disk
might be costly. Hopefully, we can decide to store the UP form and
compute back the normalized form when restoring the DN. This operation
(normalization) is less costly than the parsing. This is something we
can trigger if needed, but I don't think this is urgent, unless we
really want to manage millions of DNs right now :)
I have also tried to improve the serialization so that we don't save a
UP and normalized value if they are equals. That come at a cost, and
it's not perfect.
I still have to go deeper, regarding the UP index.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
