[ppml] LDAP? Why not?

[Leslie Daigle]

Responding to your assertions that I have misspoken:

Michael.Dillon at radianz.com wrote:
>>FYI, for documentation of a project that put considerable
>>effort into attempting to do just that for domain whois, see
>>http://www.ietf.org/internet-drafts/draft-newton-ldap-whois-03.txt
>>In particular, Section 6 ("Lessons Learned") describes pretty
>>plainly the disappointments that LDAP could not be used "out
>>of the box".
> 
> 
> I've read this document and the lessons learned are not what you claim.
> In 6.1 they seem to be complaining that their original plan to map
> the hierarchical domain name structure onto a relational database
> caused problems. Perhaps that's because a relational database is not
> a good datastore for hierarchically structured data? In any case, there
> is more than one way to map an LDAP schema onto a relational database
> and not all of them suffer this problem.

Really?  My reading of 6.1 is that it describes how LDAP
*implementations* did not consistently support the LDAP features
that would have allowed the server to run with a generic
database.  To compensate for that, a special-purpose backend would
have to be written.

My point:  LDAP (implementation reality, not protocol) is not as
off-the-shelf as we all would have liked to believe.

> 
> In 6.2 the author points out that the issue was not with LDAP but with 
> a characteristic of the problem they were trying to solve.

Sure -- but I'm not picking on LDAP, I'm speaking to the applicability
of LDAP as a tool for the problem you're trying to solve.   To the
extent that you're trying to solve an analogous problem, LDAP
(and the referral model, which is what 6.2 is actually talking about)
isn't the right tool.

> 
> In 6.3 the author points out that they could have designed a better schema 
> 
> if they had considered the needs of their GUI search client.
> 
> In 6.4 they discovered that there are no magic bullet solutions that will
> do everything for everybody. Just because SQL is a standard database
> access method doesn't mean that you can make a useful SQL client to access
> any SQL database. Same thing with LDAP.

But this is a key issue.  Many (and I'm not saying *yours*, necessarily)
arguments for using LDAP are based on the assumption that there exist
software clients and servers that will be able to use it straightaway.

6.4 highlights that's a (critical) misconception.


> 
> In 6.5 the author noted that they could have designed a more effective 
> data
> model if they had used DNS SRV records to locate the appropriate LDAP 
> server.
> 
> In 6.6 they noted that some people really want a bulk data download 
> capability
> and a directory service isn't a good way to do this.
> 
> None of these lessons indicate a problem with LDAP.


Agreed on the last point -- the document was about an experience
of applying LDAP to a particular problem set.  As you have noted,
some of the issues were with the particular model used.  But some
of them are *not*, and I believe the value in having them written
down is to allow others to learn from the experience before embarking
on the identical path.

Your statement was that "if everyone published their directory type
information using LDAP the world would be a better place."  You called
it a pet theory.  For anyone on this list interested in reading
about experience, not theory, the RLDAP document is worthwhile
reading.


Leslie.