Re: remote configuration sources

[Havoc Pennington <hp redhat com>]

Bob Smith <bob thestuff net> writes:
> Before gconf was thaught up, a fiew programmers and myself went over the
> concept of a configuration library and came up with an idea very similar to
> gconf except that it was alot less complex on the server side. no schema's
> or anything like that. just a registry style system with multiple
> combinable backends. We decided that configureation data was not complex
> enough to nessitate such things.

Note that a GConf schema is nothing complicated like an LDAP
schema. It's just a default value for the key, a docstring, etc.

> User data on the other hand does.

I would generally agree that the GConf API is not suitable for storing 
user data. 

> LDAP already is
> designed to do bookmarks, addressed and anything else you can think of.
> We also looked at acap and we desided that it tries to duplicate
> LDAP.

IMO ACAP is a good bit better for something like address book data
than LDAP. It is much more suitable for having generic support in a
web browser, for example, so when you sit down at the browser you put
in your acap: URI and it loads your address book.

You could probably come up with a scheme to do that using LDAP, but I
don't think the LDAP spec by itself specifies such a scheme.

Also, LDAP while more lightweight than X500 or whatever, is far more
complex than ACAP.

> > 1) make sure acap and gconf can play long term
> > 2) figure out a gconf schema/namespace/etc to store addressbook, bookmarks,
> > etc

I think Bob is right that the GConf API and general way-of-working
isn't so good for stuffing an address book into. If that's your first
priority, maybe you would want to start by doing an ACAP server (or
finding one on the net, surely someone has written this), and then
have GConf as one way of accessing the ACAP server (used for
preferences), and then a separate API for storing the address book on
that server. Or something along those lines.

It could all ship in the same tarball as a nice unified package,
GConf+ or something. ;-)

Anyhow, there's a lot of thinking to be done about how it all works,
how to make it easy enough to use that programmers can get it right
and users can use it, etc. Pretty hard problem really.

Havoc