Re: general question : why keeping it so hard ?

[Devdas Bhagat <devdas@worldgatein.net>]

On Wed, 27 Jun 2001, Prune spewed into the ether:
> This mail is a thought about LDAP.
> As databases went simpler and simpler over the past years, Ldap is still 
> as complicated to use as X500.
> You all know what I'm talking about : Schema.
Ummm, the schema is not tough to understand. Its the documentation that
sucks, but I still haven't been able to figure out better
documentation, so I guess I can't complain. You should know what I'm
talking about: Documentation is like sex, When it is good, it is very
good, if it is bad, well it is still better than nothing at all.

> As long as you use normal schema, there are no problem. But if you
> want to do something special... 
Well, I'm writing my own schema :)

> Moreover, Schema are not compatible between different ldap servers 
> (netscape, openldap,...?). 
I guess we need a naming standard for attributes. Any takers?
 
> This question arize : What can be done to use LDAP without having to 
> deal with Schema ?
Ok, let me compare LDAP to databases.
You have a DBA who decides on the structure of your database, knows
SQL...... Similarly, you need a LDAP admin who decides these things.
your programmers who write applications need not know everyhting about
the LDAP tree, they have to know the API and the permissible types of
values in the tree. No one other than these has to know about LDAP.

> Of course, a good product, implementation dependant, could deals with 
> Schema for you. Some kind of Schema constructor. I haven't found 
> anything interesting yet :(
Hmmm, a pretty GUI interface to design schemas? shouldn't be that tough
with HTML and a few drop downs in a form.

> I think Schema is THE thing that disable Ldap to be used at
> it's best.  
Its not a schema, but the lack of good documentation.
For someone not familiar with any X.500 concepts, LDAP is a tough
thing to wrap ones brains around.

The biggest clue for beginners who are familiar with databases is:
The dn is the equivalent of the primary key in a RDBMS
All other attributes are values.
Your data is stored in a tree form, instead of tables (think BSTs
against arrays). 

> Even if LDAP V3 add some functionalities, it's still hard to use.  
Sure, SASL is a big pain, with the lack of documentation there.
Documentation on why you need OIDs isn't easy to come by.

I will not say that the OpenLDAP documentation is bad, its the docs for
various support libraries, and the basic conecpts that is lacking.

What a user will need to know often is the logic behind tree design.
Why use a tree over a database? How many writes will be excessive?
I have this value that needs transactional integrity, and all these
values that may or may not exist. What do I choose, a database or LDAP?
These questions need answering

> I would really like to know what other people on this mailing list 
> think.  
> Maybe we are at the begining of a new LDAP_without_schema tool ?  
Hmmm, and how does this handle the various types of data?
A schema is merely a description, like a XML DTD, or a css. All that a
schema does is give names to various data types.

See typedef in a C programming book.  

Devdas Bhagat
--
If elected, Zippy pledges to each and every American a 55-year-old houseboy ...