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

[Thomas Leonard]

On Thu, Jul 22, 2004 at 11:54:18AM -0400, Patrick Patterson wrote:
> On Thursday 22 July 2004 10:59, C. Gatzemeier wrote:
[...]
> > A particular thing you seem to address that CFG does not yet have is a
> > notion for is handling of notifications. Another thing is d-bus, which was
> > not yet there when CFG was first planned, but would fit in there very good
> > now. Maybe you would like to have a look at the architecture and see if
> > your ideas could be applied.
> 
> I just joined the list a few days ago, during the DDC in Ottawa, so I don't 
> have the whole historic on this, but it sounds like what you are talking 
> about already exists - for those of you who attended the DDC, you should 
> recognise it - UniConf - the Universal Configuration Framework... it handles 
> replication, cacheing, notifications, as well as the standard "get/set" type 
> configuration issues.
> 
> (It also talks and plays nicely with gconf, the Windows registry (did I 
> mention it's cross platform :)), KConfig, etc.
> 
> http://open.nit.ca is the current home for it, so please take a long look at 
> it before designing something that this might just solve :)

I was at the DDC. The UniConf talk was very impressive technically
(configuring KDE from gconf-editor using a mailbox for storage!).

I certainly think there should be some discussion of it here.

My impression (just from the talk):

Good points:

- Everything is a string. Clients and libraries interpret them as they
  please.

- Can work with or without a daemon process.

- Good support for caching, fallbacks, multiple backends, legacy support
  for other systems.

- A single process can access the same information in different ways, by
  'mounting' different config backends onto a namespace.

- The system can be useful beyond just configuration; eg a /tmp namespace
  for doing notifications within an application.

- Command-line tool to get and set values. Very useful for scripting!


Issues:

- 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.

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

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

- 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.

- Is anyone else using UniConf?


-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk	tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1