Re: How about the progress of gconf backend ldap support?

["Dave Cridland [Home]" <dave cridland net>]

On Tue, 2003-01-14 at 03:19, Havoc Pennington wrote:
> On Tue, Jan 14, 2003 at 11:20:05AM +0800, Calvin Liu wrote:
> > It's said that gconf will support "A network server backend - based on
> > http, ACAP, LDAP, a custom protocol, or whatever, is really required for
> > environments where CORBA connections between machines and NFS/AFS mounts
> > aren't adequate."
> > 
> > When will it be finished? Any schedule?
> > 
> 
> "When someone finishes it" ;-)
> 
> Kristian Rietveld was doing some work in this area.

As am I, but I'm doing ACAP, because it's, er, designed for this precise
application.

I haven't, yet, made any real start on the gconf-backend for it, though.
If anyone wants to have a crack at this, I'd be happy to help, of
course.

I do have 95% of an ACAP server. It is definitely losing data at the
moment, but I know where. Until I'm confident that it isn't losing data
under any circumstances, and that even if it crashes, a client is
unlikely to be unaware of data changes, then I will NOT release it under
an OSF license.

Once I think it's relatively safe to use, then it'll be released under
some form of OSF license, most likely GPL, assuming that either:

a) This allows the server to link to OpenSSL and Cyrus-SASL.
b) I can finish off the minimalist inbuilt SASL, and make SSL support
optional.

The obvious next stage would be to agree on a dataset definition for the
server. We have several options here:

1) We can grab a vendor tag, and build our own, without recourse to any
existing standard dataset specifications.
2) We can grab a vendor tag, and build our own within the (draft) option
dataset.
3) We can formally submit an IETF draft, specifying a standard gconf
dataset. In theory, this would mean we were interoperable with, er,
other implementations of gconf. :-) The main problem would be namespace
division within our standard dataset would be problematic. (How is this
solved at present?)

There are also the following issues to consider:

i) What's the state of play WRT authentication for gconf backend
sources? Existing sources don't require authentication, as I understand
it.
ii) Should we attempt to provide some direct interface to ACAP datasets?
There are (draft) specifications for bookmarks and "personal address
books", both of which are currently stored by existing GNOME
applications in gconf. (Galeon, Evolution). If these were stored in
ACAP, then in theory, other, non-GNOME (and indeed non-Linux)
applications could see the data.

Dave.