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
[EMAIL PROTECTED] wrote:
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.
-- Andrew Newton
