Tools

Mon Mar 3 16:32:56 UTC 2003

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 at karoshi.com 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