Why is LDAP so complex?

[Tony Bibbs <tony@tonybibbs.com>]

OK, I'm a bit frustrated with LDAP...partly because sometime I rush
things and make stupid mistakes but also in part by LDAP being much more
complicated than I think it should be.

Here's some thoughts from a newbie on how LDAP could be improved.  I'm
guessing this may not be a totally original idea but I haven't heard
anybody asking for this.

I think that LDAP is more complicated that it needs to be.  Particularly
with the syntax of adding/searching/removing entries and in building
your own object classes.

Has anyone thought to write a set of programs that turns the cryptic
LDAP syntaxes into more of a usable system?

For example, LDIF files are a joke to me.  Maybe I should rest assured
knowing that understanding them now affords me a degree of job security
but why not simplify it.  Here's an example of what I'd like to see
happen

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");
$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 idea here is that the above could be ran through some sort of LDAP
interpreter that would then checks syntaxes and give more useful
messages (errors or otherwise) that aid in deploying LDAP

When successfully intepreted these can then be used to build the LDIF
files reliably and pumped through ldapadd or ldapsearch or ldapdelete.

Sure this may not seem to change anything for someone that has done LDAP
for awhile but I think this would make LDAP easier to read and debug.

Similarly something needs to be done about object class definitions.

Specifically I shouldn't have to put 1.3.6.1.4.1.1466.115.121.1.27 for
integer data types but, rather, LDAP_INT (they already did something
like this for matching rules, why not for data types?).

Again, that would be 10 times more readable, easier to use and let's me
worry about solving my problem with LDAP and not so much with LDAP
itself.

Ok, I'm done ranting.

--Tony



On Thu, 2002-01-10 at 15:13, Stefan Alfredsson wrote:
> On Thu, Jan 10, 2002 at 08:56:29AM +0100, Pierangelo Masarati wrote:
> > Stefan Alfredsson wrote:
> > > Is it possible to do a partial replication, i.e. only certain attributes
> > > are taken into consideration?
> > 
> > No. I'd say "not yet" because I was thinking about doing something like 
> > that some day.  A simple yet powerful solution would be to pass the data 
> > being sent to each replica thru ACLs.
> 
> I came to think about this possiblity today myself; If the replica binddn
> only has write access to certain attributes on the slave, would this
> work as expected? 
> 
> Something like this springs to mind (slave config):
> 
> access to attrs=maillocaladdress,rfc822mailmember,cn,uid
> 	by dn="cn=repl,dc=acme,dc=org" write
> 	by * read
> 
> access to *
> 	by * read
> 
> Or would slurpd fail when it has no access to modify other attributes
> on the slave? I.e. if only maillocaladdress is changed, it is successful.
> If maillocaladdress and loginShell were changed at the same time,
> there would be a conflict and the "transaction" would fail?
> 
> /Stefan