Re: backends (ldap)

[monkeyiq dingoblue net au]

>
>
> There is a standard C API to LDAP (an IETF standard, see
> http://www.ietf.org/rfc/rfc1823.txt?number=1823).

FYI there are also
RFC 1777 Lightweight Directory Access Protocol
RFC 1778 String Representation of Standard Attribute Syntaxes
RFC 1779 String Representation of Distinguished Names (DNs)
RFC 1823 LDAP Application Program Interface
RFC 2251 Lightweight Directory Access Protocol
RFC 2252 LDAP V3 Attribute Syntax Definitions
RFC 2253 UTF-8 String Representation of DNs
RFC 2254 The String Representation of LDAP Search Filters
RFC 2255 The LDAP URL Format

But no C++ ones...


> I'd say that if you're looking for something like a C++ version
> of JNDI, you will have a lot of complexity to deal with,
> since JNDI does not impose too many constraints on
> what is a "naming context", whereas you will need to
> find some way to map GConf's hierarchical key
> structures to LDAP.

I need to mangle the key for LDAP itself anyway, the other
niceness to JNDI is that it also supports NIS, Novel, and
pritty much any Directory protocol that there is. Which
would be a extra tick in GConf's list, being able to save
its data in existing netware dir servers.

>
> There's one other issue with LDAP; most deployments have
> a specific schema and use OU's to segregate different
> user's directory data;

I will probably create specific LDAP schemas for the GConf
stuff, which will hopefully happen soon. BTW you can pass in
an option as to the base rdn to use for all keyops. ie.
--key-base="dn=ben, ou=monkeyiq" then the key
/fred/key would be resolved to
"dn=key, dn=fred, dn=ben, ou=monkeyiq"
So each user can store their prefs in a different tree if they want.

> it would be really nice if
> the GConf address for an LDAP database could specify
> something about this OU structure.

I hope key-base is something like this.

>
> I've given some thought to this, if you want to take it
> to private mail, just drop me a line!

I wonder if talking about this would not be ok on the list?
it does directly effect the future of a backend, so maybe
if people don't want to know this info they shouldn't be
on the list...?

I'll post the code in next msg, so that you can see where I'm at.