Customer vs Company

[Alaric B. Snell]

On Thursday 03 April 2003 21:03, Derek Atkins wrote:

> The "broken" part is the fact that LDAP needs its own data store,
> rather than being able to perform a lookup in some other (SQL) data
> store.  The DNS (which is another example of a directory) is backend
> agnostic.  There are certainly DNS server implementations that sit
> on top of a SQL database; why can't LDAP do that?  Why do you need
> to copy the data?

You can indeed back LDAP onto SQL. Indeed, you could back LDAP onto gnucash's 
internal data structures, and have Gnucash's address book (however it is 
implemented) queryable via LDAP while Gnucash is up.

> I just think LDAP is a bane on society and should be killed as quickly
> and efficiently as possible.  It's the WORST of all worlds possible.
> Security was an add-on and not well-considered.  It uses ASN.1 in all
> the worst ways.  It really should just die, and I'll be dancing in the
> streets when it does.

I'm no fan of LDAP, either... :-(

Let's say "Screw LDAP!" and help it to die by replacing it with a lightweight 
standard involving HTTP GET and PUT to access a directory of FOAF files, with 
a standard set of URL suffixes to use to get search prefixes.

Eg, <server root>/data/<record id> can be GET and PUTted to get/set data 
given an ID string. Oh, and there's an HTTP method to do deletions too, IIRC.

<server root>/search?...search expression... can be GETted to pull back a 
list of ID strings.

<server root>/create can be POSTed to with a new FOAF file, and the response 
is the <record id> that it was assigned.

Then write an RFC, and an Evolution plugin for it, and crusade against LDAP!

> -derek

ABS

-- 
A city is like a large, complex, rabbit
 - ARP