[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: issues with full schema support (was: short names, in general (Re: Comment ..)

Timothy Hahn wrote: 

Object identifiers are "nice" in that they allow for uniqueness and
de-centralized administration/management.  But they're particularly poor
with respect to user-friendliness.


And especially there's not always a user-friendly name available.

Yes, I've heard all the arguments about "what flows on the wire is not what
people have to see".  But for every "transformation" that's required or
implied, it puts just a bit more weight on the shoulders of the, so-called,
"lightweight" client.


Never expected anybody here to make such a true statement!

I had hell of a time implementing schema support in recent web2ldap preserving user-friendly presentation, stick to local schema, resolve ambigous naming if possible, optional definitions, seriously flawed schema definitions and incomplete schema references in recent server products, abused OIDs, presenting short names vs. OIDs....... and all of that with reasonable performance.

<rant>
Frankly, if I would tell my customers what they have to consider when implementing a really LDAPv3 compliant application also interoperable with recent LDAP server products they would laugh at me and do not pay attention to LDAP anymore.
</rant>

 Unfortunately, "client" implementations that are
fully "schema aware" are few and far between - if they exist at all.

Feel free to check it out. It's not complete yet regarding syntax handling.

http://sites.inka.de:8002/web2ldap

Directly jump into browsing schema of e.g OpenLDAP's demo server:

http://sites.inka.de:8002/web2ldap/oid?ldap://ldap.openldap.org/dc=openldap,dc=org

 Add
to the problem the "feature" that depending on the area of the "tree"
you're "in", the schema to use may be different.  At this point, "client"
code throws in the towel.

My client always requests the subschemaSubentry attribute for each DN. A reasonable performance is achieved by maintaining an entry -> subschemaSubentry cache and maintaining a cache of parsed schema data strutures.

BTW: Most of the default installations of other LDAP servers have around 200-400 kBytes of rarely needed but pre-installed bloat in it. LDAP server vendors, please create admin tools for your server product which encourages directory admins to select a sub-set of schema definitions needed for the data they want to store.

Ciao, Michael.