UniConf (was: Scheduling subsystems (crontab, at) and the desktop)

[Avery Pennarun]

On Sat, Jul 31, 2004 at 01:14:32PM +0100, Thomas Leonard wrote:

> - Each application builds up its own namespace at startup. This seems to
>   mean that the backend used is determined by the application, not the
>   user. I should be able to tell all my applications to store config in a
>   remote database, or in local .ini files, or whatever, and have all
>   applications do that. Obviously this is possible, but we need a standard
>   way to do it, preferably in a library.

If you're using a daemon, this question is really moot: just connect to
the daemon automatically.

I suppose it would be easy to make any kind of UniConf "self-configuration"
thingy that we want, but we'd first have to decide what we want, which is
opposed to one of the original design goals of UniConf: just make sure we
can do whatever we want, no matter what it is.

I'd propose creating an "auto-configuration" backend that constructs its
contents from a configuration file (or whatever).  Then programs connect
their UniConf up to "autoconfig:desktop/gnome/apps/MyAppName" or something,
and autoconfig will do the rest (eg. open /etc/uniconf.conf and figure out
which config backend should be used for a config system of that type).  The
important thing about the "autoconfig" backend is that it will guarantee you
get persistent storage *somewhere*.  Exactly where, I'd like to leave up to
someone else to specify.  In fact, the entire implementation of the
autoconfig backend could vary between desktops or even Linux distributions.

> - We need to define shared keys and arrange a namespace that people can
>   add to without collisions.

The private namespaces are easy: I recommend doing something like the object
naming scheme in dbus.  Maybe even use that scheme exactly, since it's,
well, just a string.

Shared namespaces (eg. this is where the hostname is, this is where the
username is, this is my timezone, etc) are always hard.  Someone has to go
and standardize these and get people to follow the standard.  There's no way
out that I know of.

The way we use UniConf in our proprietary products is like this: every app
has their own private namespace, and we provide "service" programs that copy
configurations around between the namespaces.  So, for example, if someone
changes the hostname, we write the hostname into all the various places in
the DNS server's configuration file.  This works great for legacy stuff (ie.
everything) that's not "designed for UniConf", but obviously a
centrally-agreed-upon standard for the most common options would save us a
lot of work.

> - "Computers are fast". Still, at login you have a lot of applications
>   reading in a lot of settings. Some benchmarks would be reassuring.

This is a good idea, but I can tell you right now that parsing is not the
slow part.  The slow part will be transferring across the network, between
apps, from the filesystem, etc, which are: a) not UniConf's fault, and b)
intentionally well-optimized in UniConf (ie. the network protocol is
actually efficient and latency-optimized).

> - How tied up with wvstreams is uniconf? It doesn't look like there's a
>   separate release, or a way to build it separately. It would be good to
>   be able to try it out on its own.

If UniConf is rejected for any reason, this will be it.  The focus of effort
right now is to extract it from its WvStreams roots, which will not be as
difficult as it might seem at first glance.  People wanting to work on this
should join the wvstreams-dev mailing list.

There is already a C binding, but UniConf is natively C++.  I can imagine
some people objecting to that as well, so we want to make the C binding as
clean as possible so you don't know you're even linking with a C++-based
library.  This is another important reason to reduce the dependency on
WvStreams.

> - Is anyone else using UniConf?

Almost certainly not.  But you're using something it's based on :)

Have fun,

Avery