Re: config library. Was GNOME registry

[Rene Mayrhofer <rmayr vianova at>]

>A thought:
>
>Applications should not directly open/read the local config database.
>There should instead be a config server with which apps communicate
>(CORBA).  The libCFG API would of course hide all this.  The server
>would "own" the local config database.
For sure I would like to have the entire communication handled by CORBA,
but how about other programmers that don't like the idea of CORBA ? 

>Reasons:
>
>1: This will be the same interface over which a remote management entity
>can access the database - it's just another client.
In the terms of abstraction I agree totally.

>2: Avoids race conditions (what if the d/b is partway through an update
>when an app reads it?)
Exactly.

>3: Provides an interface by which apps can be notified of changes to
>their config.  Many apps won't _use_ this, but it should be there.
Agreed.

>4: If the apps can modify the d/b (they should be able to, but
>permissions will get tricky) then the well-debugged server can validate
>the update.  This prevents buggy apps from trashing the registry.
Maybe some kind of transaction processing like databases do ? Then the data
could be restored to a consistent state when an application craches during
writing into the registry.

>5: If the app is not using notifications then the API is the same as the
>one you propose with direct file reading.
This one is a must-have.

>6: This way an app's config can be in local files, on a remote machine
>or calculated on-the-fly by a smart server somewhere on the network. 
>It's all seamless and heterogeneous.
I like the transparency for programmers AND for sysadmins.

>7: The server can provide the logging, authentication and backout
>services.
>8: The server (or maybe the libCFG layer) should know about multiple
>data sources.  Some of the app's config could be in the local database,
>some may be served by a server elsewhere.  In an enterprise situation
>you may wish to have a centralised server for all client machines,
>although this doesn't show a lot of confidence in your replication and
>propagation mechanisms :-).
That would also be nice.

>Under this scheme I don't quite see where XML fits in.  The
XML could be used for ASCII files storage. Then we have a structure in the
files and we also can change them by hand if something goes wrong (I always
hated that about the Windows registry).
>client-server messages will be CORBA encapsulated binary objects, no? 
>The database would only be XML if it was flat-file, which seems
>inefficient.  I like the idea of using XML, but I'd have thought a
>relational d/b talking CORBA would be more appropriate.
It can be used if the users want it, but I don't think that it should be
required. Some are happy with text files and their inefficency. I would
also use some other kind of storage (maybe LDAP), but that's only my opinion.

>Bear in mind that it'd be great if this mechanism could allow us to
>administer legacy config.  For example, consider, ummm, /etc/fstab. I
>doubt if we can go and change getmntent, mount, nfs, swapon, etc to use
>libCFG in a hurry, so someone would need to develop the config server
>plugin which knows how to convert the server's fstab CORBA messages into
>the format required by /etc/fstab, write out the new fstab and then run
>'mount'.  Of course this is what the linuxconf modules do.
Cool. I didn't even think of that.

I would really like to hear what others think about the use of CORBA. I am
not sure if e.g. ORBit is too big to use as a standard way of
communication. It would be really cool if CORBA (and only CORBA) would be
used for the interfaces between the server and the client. How much
ressources does ORBit use for local-machine (inner-process) communication ?
Would it be too much to use everytime ? Any disadvantages of CORBA in this
case ?

Rene