Re: config library, was GNOME registry

[bob smith <bob kehs ksd org>]

The propogation stuff should be handled by the modules. Some protocols,
LDAP, and NDS, take care of that themselves.


I have been thinking. Is it nessicary, for configs, to get much more
complex then name=value, and the ability to group them?

On Fri, 1 Jan 1999, Andrew Morton wrote:

> 
> Fascinating discussion, and I'm glad to see Joshua pulling it back from
> implementation to requirements.  Carts and horses...
> 
> We are confronting what I consider to be Unix's single greatest
> weakness: system management.
> 
> - Every application has its own specific config files.
> 
> - There is no coherent interface by which higher level management
> systems can 
> manipulate those files.
> 
> - There is no coherent mechanism by which an application is informed of
> changes to its config (edit/sighup doesn't cut it).
> 
> These immaturities are a great barrier to managing large numbers of Unix
> machines.
> 
> Now I wouldn't expect the gnome team to be able to solve these problems
> - a complete solution (definitely CORBA based) would be more complex
> than NIS, LDAP and DNS combined...
> 
> But if we can identify the end requirements and you folks can implement
> a step along the way it'd be a huge contribution to Unix's viability in
> the enterprise.
> 
> Additional requirements would be:
> 
> - That a higher-level management system be able to propagate information
> to many hosts, with, of course, per-host variations
> 
> - That there be an audit trail of changes.
> 
> - Backouts
> 
> - When hosts are uncontactable, changes be propagated when they come
> back up
> 
> - etc.  I assume NDS et al do all this.
> 
> - Any host must be able to propagate information to others - not just a
> pure top-down hierarchy.
> 
> At the client side:
> 
> - Persistency (obviously)
> 
> - notifications to the running applications. This is _complex_ if the
> schema goes much beyond name=value.  You may, for example, require that
> a number of information elements be sent, but that they not be committed
> until they all have arrived at all hosts.  Otherwise they are backed
> out.
> 
> - adaptors to/from all those legacy apps which are beyond our control.
> 
> 
> So where does it stop, and how far is the gnome team prepared to go??
> 
> Within the telecommunications industry (Nortel, at least), we refer to
> this problem as "datafill".  Some of the guys here have done quite a bit
> of research in this area and I may be able to open up that thinking if
> the will is there. I'll keep watching..
> 
> Cheers,
> Andrew
> 
> [ Please, nobody say "this is off topic, take it elsewhere".  It's more
> important than gnome itself. ]
> 
> 
> "Joshua R. Prismon" wrote:
> > 
> > Actually, this is where XML would be very usefull.
> > 
> > I think we are getting ahead of ourselves here. What
> > are the requirements for what we want to do?
> > 
> > 1) Provide a generic/cheap interface to get/set configuration information.
> > 
> > 2) Provide some mechanism where we can store config information in a
> >         number of ways.
> > 
> > 3) Provide some mechanism where a universal control application could be
> >         designed.
> > 
> > 4) Provide someway to ensure that configuration information is not vunderable.
> > 
> > So here is what I fleashed out beyond that:
> > 
> > 1) Provide a generic/cheap interface to get/set configuration information.
> > 
> > Additional requirements:
> >         - Usable from any language (corba?)
> >         - Linkable into a exec for non Gnome Applications?
> >         - Handle failures (LDAP database going down, for example) gracefully.
> > 
> > In my opinion, it would be easy to do this in a Unix Library/Corba Service.
> > (speaking
> > of which, while KDE and GNOME haven't gotten along very well, this would be
> > a great
> > place to try and unify the two teams. It would ensure that we don't spend
> > massive amount
> > of time rebuilding each others code. (ie, both control panels could
> > configure anything).
> > 
> > 2) Provide some mechanism where we can store config information in a
> >         number of ways.
> > Adition Requirements:
> >         - Some sort of caching method?
> >         - Translators (ala what COAS and LinuxConf are doing).
> >         - LDAP/Text/DB formats.
> > 
> > 3) Provide some mechanism where a universal control application could be
> >         designed.
> >         - This is where XML would be usefull. We could have applications give
> >          us XML structures to desribe the data. using these XML structures, we
> >          can create a universal control panel that would be capible of admining
> >          anything, so long as it has a XML struct for it.
> > 
> > 4) Provide someway to ensure that configuration information is not vunderable.
> >         - this would be why you would want to store info in a text file. Further, we
> >          have to assume that there is some way (a text cache?) to boot up a system
> >          even if some of the configuration services (LDAP or a corrupted DB) are
> > down.
> > 
> > --
> >         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
> >          To unsubscribe: mail gnome-list-request@gnome.org with
> >                        "unsubscribe" as the Subject.
> 
> 
> -- 
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail gnome-list-request@gnome.org with 
>                        "unsubscribe" as the Subject.
>