Re: [Setup-tool-hackers] Re: [Config4gnu-developer] Re: Re: CFGconfig management (/etc etc.)



On Thu, 27 Nov 2003 11:10:16 +0100
Lars Hallberg <lah@micropp.se> wrote:

> Justin Yackoski wrote:
> 
> >I think that what you guys have done is great, and hate to see
> >duplicate effort.  So lately I've been thinking about the differences
> >between CFG and GST to try to figure out what we have in common and
> >how we might be able to join forces.
> >
> >Unfortunately, it seems that the only thing we could potentially
> >share is that CFG's parsers could probably be used by GST, but the
> >XML from the GST frontends would first have to go through an
> >intermediary that was a lot smarter than CFG's parsers.
> >  
> >
> 
> If the CFG midellayer have some kind of service id and version control
> on the XML excanged with the frontend, it must be possable to add 
> 'alternative' fatter frontend moduls. And if the versions don't agree,
> simply fall back to the generic frontend.
> 
> Must be a huge win without giving up any freedom in ui design. And 
> reduce duplicaton of effort significantly!

There should certainly be a version/revision control system applied to the XML as it goes thru the middle layer.  We don't do that right now, but it is one of the features we feel are very important.

As for the service ID, such as saying "give me the config for the system's primary network device (eth0, ppp0, etc.)" or "give me the config for samba" without knowing the exact path (i.e., /services/samba), I think supporting fatter front ends or other tools is a very good reason to include this.  There are a couple of ways we could implement this, but probably the simplest is just to create a list of mappings from service ID to their path in the master XML document that CFG edits.

If CFG was able to do this, would other config tools consider using it for a fair portion of their behind the scenes stuff?  Or are there still other issues to be resolved?

> BTW, do CFG have any stable 'virtual' interfaces for seting upp
> standard stuf - preferably with an option to do it only temporarly
> (ie, reset on next boot). Would be great for stuff like DHCP scripts
> and curently, netenv that I use and need to set different nameservers,
> domain, hosts depending on the conection point - but without
> disturbing the 'default' config. Just prepering some set of XML files
> to feed the cfg depending on environment, leving all the details of
> config file format and changes in them to the cfg would be great :-)

We have a working demo of a "script interface" to CFG.  You can basically use a DOM interface to get at something's configuration, change some values, and save your changes.  CFG doesn't do revision control currently, but you could easily create one script to setup each of your different environments, and then one more that sets everything to its defaults.  

In our CVS, see /config4gnu/test/perl/sample_perl.pl for an example of getting & reading a config file. (you'll have to do a make test in /config4gnu/test/perl to create it)  Just set the values you'd like, and then call save() on the object you get from the resolve_path("/Whatever/Something") call, in the example script this would be $samba.  (Jason please correct me if I'm wrong).  

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com
_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/setup-tool-hackers



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]