Re: config library. Was GNOME registry

[bob smith <bob kehs ksd org>]

As to the corba idea, I think there should be corba wrappers to the
library, but the main library should not contain it. The modules could
contain corba
as well.

The library should be as simple as posible but still look to the future.
The API should stay the same but the modules can do just about whatever
they want.
If we make the API too complex it will drive some programmers away.
The idea is to make the library easier for the programmer to use then to
code up there own. Throwing in alot of corba to programmers that have
never seen it would be a "bad thing". 

On Sat, 2 Jan 1999, Rene Mayrhofer wrote:

> >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
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>