[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.