UniConf (was: Scheduling subsystems (crontab, at) and the desktop)
tal00r at ecs.soton.ac.uk
Sat Jul 31 15:14:32 EEST 2004
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):
- Everything is a string. Clients and libraries interpret them as they
- 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!
- 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
More information about the xdg