Hi guys,
thanks for your comments on this very preliminary page. More inline.
Alex Karasulu wrote:
On Mon, Jul 14, 2008 at 2:51 PM, Howard Chu <[EMAIL PROTECTED]> wrote:
Ah, looks like a quite familiar pain. Just a note, in X.500/LDAP docs what
you called an ATAV is known as an AVA. Might want to line up the terminology
to make the correspondence clearer.
+1
Will switch to AVA, sure.
And may I suggest another optimization to consider - for your AttributeType
internal structure, store a reference to the schema element, not a
normalized OID.
I think this is a good idea and something we've debated. Our problem comes
from the fact that this LdapDN class and it's LdapDNParser is way
overloaded. We keep making some things serve more than one use. Namely
referring to the fact that these classes are designed to work in clients and
servers : hence the reason for sticking to an OID. Not all clients are
going to want to waste the time to perform a search over schema subentry
attributes to resolve, parse and generate the AT representation.
There is a reason why the LdapDN was not using AttributeType ( our
internal 'pointer' to the schema ), it's that the DN are parsed during
the LDAP protocol decoding. When it was first done, we didn't had easy
access to the schema objects. This was debated from the begining (should
we parse the DN while decoding the PDUs or not), and I'm not really sure
I was right to push this idea. May be it's better to parse the DN later
(but then, when ? The problem is that we need the DN pretty early, even
before passing through the normalization Interceptor.)
Anyway, the idea here is to put everything on the table, and start to
think again with some open mind.
Second point, raised by Alex, the fact we have a client/server mixed DN
object may be over killing, and a separation would be good to have.
Currently, this is done through a call to a Normalize method, which is
not the best way to do it, because we also have to do the prepString
before, and also because the client DN does not need this method.
My mindset on these matters is very RISC+UNIX'ish in their nature. Write
something that does only one thing and does it well, simpley, in a managable
and efficient manner. That's why I think we need to break up this LdapDN
into ClientDn and ServerDn. You can add the LDAP part to these names but
I'm not worried about the naming right now: just that we need to break these
suckers up.
+1. I will start thinking about it. LdapDN and ServerDN sounds good to me.
Another idea we have had would be to write a very fast DN parser which
assumes that a DN is composed of ASCII chars, with a single AVA per RDN,
without any special chars like " or +. If we fall into a special case,
an exeption will be thrown and we fall back into the complex DN parser.
this may save us a lot of CPU cycles...
We're paying for an overhead in complexity and performance because we're
trying to generalize one implementation to solve two different ways of
dealing with handling LDAP distinguished names.
I'm not sure that we are paying a huge penalty in term of performance,
but in term of complexity and maintainability, it just sucks ... Even
for me ;)
You're going to need to dereference fields of the schema definition
frequently when dealing with it anyway,
Yeah big time.
+1
e.g. to find the syntax and what normalization rules it uses. And, whether
you take this approach or not, you need a strategy for dealing with
unrecognized attributeTypes. I.e., right now you're using the OID, but what
happens if you're unable to find the OID?
Another excellent point.
Currently, if the OID is not found, then we consider that the DN is
incorrect, and we throw an error. This is done during the DN
normalization. Is that the correct behavior ? (Assuming that we handle
correctly the referrals and extensible ObjectClass... To be double
checked ! Did I forgot any other case ?)
Presumably the schema is always resident in memory, and a reference will be
the most memory efficient...
+1 for the server dn and it's parser.
Thanks for chiming in Howard. It's always good to have your input!
Damn yes !
More to come on the DN parsing page. I have 4 hours in the train
tomorrow, perfect time to write doco.
Thanks guys !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
