> Too many features layered on a single tool. Haq the tool
> and the dependencies will cripple your service offering.
LDAP is not a tool, it is a protocol that can be used by many tools to
communicate in the same way that many servers (BIND, NSD, DJBDNS, MS-DNS,
QuickDNS) can use the DNS protocol to communicate with countless clients
(Netscape, sendmail, ...).
tool in the generic sense. too many things that depend on
LDAP for proper functioning -will- make LDAP a tempting
target.
Once this begins to provide benefit in North America, the rest of the
world will soon follow.
presuming facts not in evidence.
So not functioning properly is preferable to depending on a tempting target for proper functioning?
I'd like to stop this argument now by saying you are both right.
*) LDAP is a protocol, not an implementation. The back-end can be anything... even monkeys with pencil and paper.
*) Michael's point about doing things differently and hopefully in a better way does not hinge on technology... it is a matter of will. The technology exists.
*) In order to run an efficient public-facing LDAP server that scales to the order needed by many but not all, off-the-shelf vendor software will not suffice.
*) LDAP in its current form does not contain the operations or data types needed by this community. However, it is an extensible protocol and anyone with a source-available or pluggable implementation will not be starting from scratch.
*) Having to extend the protocol means that generic clients are of limited use but not unuseable.
*) As Stephane said, there are a number of people looking at this in the IETF CRISP working group. And LDAP is one of the proposed solutions.
-andy
bmanning@karoshi.com wrote: