Re: Why is LDAP so complex?

["Mark H. Wood" <mwood@IUPUI.Edu>]

On 10 Jan 2002, Tony Bibbs wrote:
> Take this example (taken right from the openldap quick-start guide)
>
> dn: dc=example,dc=com
> objectclass: dcObject
> objectclass: organization
> o: Example Company
> dc: example
>
> dn: cn=Manager,dc=example,dc=com
> objectclass: organizationalRole
> cn: Manager
>
> Why not create a simple object'ish language that allows all that to be
> defined as follows:
>
> $myentry1 = New LDAP_ENTRY("example.com");
                              ^^^^^^^^^^^
You just lost information.  What kind of object is "example"?  What kind
of object is "com"?

> $myentry1.InheritClass("dcObject");
> $myentry1.InheritClass("organization");
> $myentry1.o = "Example Company";
> $myentry1.dc ="example";
> $myentry1.add();
>
> $myentry2 = New LDAP_ENTRY("manager.example.com");
> $myentry2.InheritClass("organizationalRole");
> $myentry2.cn = "Manager";
> $myentry2.add();

The rest of this merely moves imperative verbs after their subjects, just
as most OO languages do (rather unnaturally, for an English-speaker like
me).  And I find the intransitive use of "add" to be particularly jarring.

By the way, where are the destructors invoked?  Do $myentry1 and $myentry2
persist until the program exits?  I'd consider that a massive memory leak.
OO forms are really too general for heavily stylized things like
configuration languages, and doing it "properly" is going to make the
resulting config.s very wordy.

LDIF also has the nice property that it's defined across multiple
products.  That's what the "Interchange" bit means.  Well-written LDIF
data should be transportable.

Now, if you don't mind forking off an (initially) OpenLDAP-specific
alternative to LDIF, and your goal is to make the grouping of attributes
more explicit, consider something like the configuration languages used by
BIND or Kerberos:

create {
	dn={dc=example,dc=com}
	objectClass={dcObject,organization}
	o="Example Company"
	dc=example
}

Another thought is that you might meet less resistance if you implement a
translator which can transform LDIF to your new language and vice versa.
That way it's easy to bolt it onto any product which currently uses LDIF.
If your new language catches on, it can be folded into the products later.

However, if your main problem with LDIF is the quality of the error
messages, then maybe you should spend some time improving the error
diagnosis and recovery in OpenLDAP's LDIF parser.  That would not only be
a useful contribution to OpenLDAP, but also provide valuable experience
with the language which would inform your later work in devising a better
one.

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Our lives are forever changed.  But *that* is exactly as it always was.