Re: config library. Was GNOME registry

[bob smith <bob kehs ksd org>]

Well, a server might be a good idea for the flat file modules. Using a
server for the ldap module an others would just slow things down.

As to handaling programs that dont know about the library, I think some
other program should be written. In the end, if this library is written
well enough, everyone will switch to it. Alot of extra code in the library
for handling old programs would be ugly. Maby Linuxconf could be used for
the old programs.

 On Sun, 3 Jan 1999, Andrew Morton wrote:

> bob smith wrote:
> > 
> > I have put up a page.
> > http://www.thestuff.net/libcfg
> 
> Is good!
> 
> 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.
> 
> Reasons:
> 
> 1: This will be the same interface over which a remote management entity
> can access the database - it's just another client.
> 
> 2: Avoids race conditions (what if the d/b is partway through an update
> when an app reads it?)
> 
> 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.
> 
> 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.
> 
> 5: If the app is not using notifications then the API is the same as the
> one you propose with direct file reading.
> 
> 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.
> 
> 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 :-).
> 
> 
> If we need to import/export to/from flat files then a trivial client can
> connect to the server and do this.
> 
> Under this scheme I don't quite see where XML fits in.  The
> 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.
> 
> 
> 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.
> 
> - Andrew.
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>