config4gnu-developer — Config4GNU developers list

[Config4gnu-developer] Re: Re: CFG config management (/etc etc.)

[<p.c...@ar...>]

Hello everyone,

and thank you very much to the people who commented on CFG.

Carlos Perell=F3 Mar=EDn wrote:
> > This is a proposal for a config file handling framework.
> > Config4gnu or CFG for short is unlike the config "tools" existing
> > today.
>=20
> It's something like the GNOME System Tools' backends

Oh, indeed. I am sorry, I did not know about them before. Thanks for pointi=
ng them out.
Reading your website it looks like CFG and GST have a lot of common ideas, =
and that GST has allready come a long way in making really nice frontends a=
nd grafics

As I understand the Gnome tools also use abstracted XML Data to communicate=
 with their current backends.
The difference seems to me that GST have started from the need of a System =
Tool for GNOME (well that is actually the name ;-) ) whereas CFG was inspir=
ed to have a nice framework for flexible and simplified handling of any /et=
c configuration, systemwide.


> > In the future these definiton files can be maintained within
> > the different software packages so that its central configuration is
> > instantly availabe upon installation.
>=20
> I don't see the beneficies for that kind of "rendering" the settings,
> it's just like a normal edit but it does not hide the complex tasks, you
> only have key/value entries with some extra information

Yes just having keys and values is not really user friendly, that is why CF=
G is not limited to them and has also wizards and forms, however the keys a=
nd values are interesting for the applications themself if they want to rea=
d their configuration through the config4gnu (allready validated and with d=
efaults)

> lets you add any backend easily but what will you win with that? web
> browser GUI?


Am I correct that in order to configure a new thing with GST one would need=
 to write a new module. (i.e a Gnome Frontend and a Backend) And other Inte=
rfaces (KDE, XFCE, etc.) would also need new modules?

The approach in CFG is to have the configuration logic be within a middlela=
yer, so every Frontend that queries CFG can configure anything the middlela=
yer has a definition file for.
All applications weather they are GUI-, text-, scipt- or API-based can make=
 use of the same configuration wizards, forms, related documentation and he=
lp for a service without nessecarily knowing anything about the service its=
elf.

Another nice thing is, that nothing in the middlelayer or the backends is h=
ardcoded to configure just a particular programm.

To support a new application distribution independent in all frontends only=
 its meta-configuration datais needed. (syntax, options, defaults and logic=
 in the form of an xml file)


Here I have copied some notes from Damien Uern who was also looking into GS=
T and CFG. Trying to benefit both he writes:

----------
> [GST] don't address the problem of=20
> simplifying the /etc tree even for the user using vi to change their=20
> configuration. Providing a fast, small, library that applications can inc=
lude=20
> to resolve the path to their config files is a good step to improving the=
=20
> /etc file tree because then distributors can clean it up without breaking=
=20
> apps or having to hack the code to those apps.=20
>=20
> The problem with CFG is that it wants to change every program that sticks=
 a=20
> file in the /etc directory. But IMO, this is a good thing, and I believe =
all=20
> the Unix/GNU tools need to move towards a more structured, more logical=
=20
> configuration system and have less reliance on hard coding paths at=20
> compile-time (this goes for hard coding locations of data directories as=
=20
> well!).=20

I do not understand, how would CFG try to change the programs?
=20
> CFG also has the right idea in trying to get developers to include CFG XM=
L=20
> files in their program distribution so that, on installation, it is insta=
ntly=20
> supported by the GUI tools, even though the GUI tools haven't been=20
> specifically programmed for it. It seems that with GST, they have to=20
> explicitly add support for everything at the frontend and the backend.=20
> =20
-----------


Have a good day!
-Peter




>=20
> >=20
> > So far CFG provides a unified configuration API for all kinds of
> > config files on a single machine. Frontends for WWW, GTK, comand line
> > (scripts) or programms using the config4gnu API directly all see the
> > same "configuration tree". Config4Gnu provides logic/consistency
> > checking, activation of changes, "configuration wizards" and more. But
> > at all times only the config files under /etc are authoritative and
> > are still fully hand editable including the comments.
>=20
> Just like GNOME System Tools' backend :-P
>=20
> >=20
> > The CFG parsers (backends) understand the syntax based on the
> > config-file definition and dynamicly generate a xml representation of
> > it. If a logic-definition is also available the middlelayer knows wich
> > settings are common with other packages, which help texts are
> > relevant, how to activate changes, etc. and about wizard and test
> > logics.
> >=20
> >=20
> > CFG is not limiting the personal choice of configuration file style
> > for a programer, yet he has all the fancy stuff at hands easily. He
> > could even use the Config4Gnu system directliy to parse and generate
> > the configuration files for his application.
> >=20
> > According to the two main developers the system is fully functional
> > and can edit many config formats.  It supports samba nearly fully. But
> > it is not ready for public use yet. For example some dependencies need
> > to be cleared.
> >=20
> > Before the project started last year there had been an introductory
> > article and discussion about it on freshmeat.
> > http://freshmeat.net/articles/view/565/
> >=20
> > To find out more about CFG visit=20
> > http://config4gnu.sourceforge.net and look into our mailachives.
> > Unlike the website states there has also been a tarball released.

Re: [Config4gnu-developer] Config GUIs for End Users

[Richard S. <csa...@ui...>]

On Sun, 2003-11-09 at 05:56, Justin Yackoski wrote:

> In theory, yes you only need a metadata file for XF86Config,
> however there is currently not a parser that would completely support
> that format.  It would not be hard to extend/modify an existing one.=20
> A minor generalization of the apache format parser would allow it to
> recognize the start and end of sections differently.  If you are truly
> interested in trying this out with XF86Config, I could get that format
> working for you sometime in the next couple of days.

That would be really cool.
>=20
> I agree, you could use our last stable version & tell us what you think.
> Assuming we stick with an XML-based API, you should be OK and it would
> give us some valuable feedback.

I'm going to check this out, thanks for your comments


On Fri, 2003-11-07 at 23:44, Jason Long wrote:=20
> I'm not sure if this is what you had in mind, but I think Config4GNU co=
uld
> handle reading/writing the XF86Config file. Your project would interact=
 with
> the configuration file with a simple API provided by Config4GNU.
>=20
> Which leads me to the question... what programming language does your
> project use?

Well, there is no project right now, at this time I'm just investigating
about the available tools.
The programming language I'd prefer is python, at least f=FCr the GUI-Stu=
ff.

-Richard

Re: [Config4gnu-developer] Config GUIs for End Users

[Justin Y. <ju...@sk...>]

On Sat, 8 Nov 2003 12:22:25 +0100 (CET)
p.c...@ar... wrote:

> 
> > I'm not sure if this is what you had in mind, but I think Config4GNU
> > could handle reading/writing the XF86Config file. Your project would
> > interact with
> > the configuration file with a simple API provided by Config4GNU.
> 
> Shouldn`t he only need to write a meta-config-description for
> XF86Config and whatever nvidia config, if needed perhaps call some
> external apps from his "forms" wizard, and be done?(Provided parsers
> handlig the needed fileformats exist.)

Jason, do we still have working support for wizards?  Even without wizards, you can still accomplish what you're looking for.  I think our wizard support is working though...

In theory, yes you only need a metadata file for XF86Config, however there is currently not a parser that would completely support that format.  It would not be hard to extend/modify an existing one.  A minor generalization of the apache format parser would allow it to recognize the start and end of sections differently.  If you are truly interested in trying this out with XF86Config, I could get that format working for you sometime in the next couple of days.

> > I should tell you that Config4GNU is in a state of flux right now...
> > I've been doing a lot of thinking and experimenting with different
> > ideas and am not sure what direction I would like Config4GNU to go
> > next.
> 
> I'am not sure if we allready are in a state to go "next", as long as
> it is not used by a significant number of people, giving valuable
> feedback for exactly this decision.

I agree, you could use our last stable version & tell us what you think.  Assuming we stick with an XML-based API, you should be OK and it would give us some valuable feedback.

In theory actually, once we had support for it, you'd just need to customize the meta-data files and you could probably get our GUI to look and act similarly to the way your GUI does (although maybe without a fancy feature or two).

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

Re: [Config4gnu-developer] Fw: Re: CFG config management (/etc etc.)

[Damien U. <car...@op...>]

Hrmm, they seem very GNOME-centric. They claim to want a cross-desktop 
solution, but I think they're just giving that idea lip service without any 
ambition to follow through. They also don't address the problem of 
simplifying the /etc tree even for the user using vi to change their 
configuration. Providing a fast, small, library that applications can include 
to resolve the path to their config files is a good step to improving the 
/etc file tree because then distributors can clean it up without breaking 
apps or having to hack the code to those apps.

The problem with CFG is that it wants to change every program that sticks a 
file in the /etc directory. But IMO, this is a good thing, and I believe all 
the Unix/GNU tools need to move towards a more structured, more logical 
configuration system and have less reliance on hard coding paths at 
compile-time (this goes for hard coding locations of data directories as 
well!).

CFG also has the right idea in trying to get developers to include CFG XML 
files in their program distribution so that, on installation, it is instantly 
supported by the GUI tools, even though the GUI tools haven't been 
specifically programmed for it. It seems that with GST, they have to 
explicitly add support for everything at the frontend and the backend.

Unfortunately, it appears GST has the backing of Ximian and the GNOME project, 
and so has more chance of taking off than CFG. Perhaps we could pitch CFG to 
the Mandrake guys and the KDE project (I would suggest SuSE because they're a 
KDE distribution, but now Novell owns them and Ximian).

Just my thoughts.

Damien

On Sun, 9 Nov 2003 10:26 am, p.c...@ar... wrote:
> Hello,
>
> GST really seems to have a lot in common with CFG.
>
> To me it seems so far that GST comes more from a desktop point of
> view/need, whereas CFG seems to be a more general system wide solution.
>
> They might even be combinable.
>
> GST has a CORBA interface!
>
> Could you as CFG developers please have a look, and maybe make some more
> competent notes. Maybe CC to xdg-list of freedesktop.org or even to
> setup-tool-hackers of GST.
>
> Whitepaper:
> http://primates.ximian.com/~miguel/helix-setup-tools.html
>
> Slideshow from GU4DEC 2003:
> http://www.gnome.org/projects/gst/stuff/gst-gu4dec-2003/index.html
>
> -Peter
>
>
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

Re: [Config4gnu-developer] Fw: Re: CFG config management (/etc etc.)

[<p.c...@ar...>]

Hello,

GST really seems to have a lot in common with CFG.

To me it seems so far that GST comes more from a desktop point of view/need, whereas CFG seems to be a more general system wide solution.

They might even be combinable.

GST has a CORBA interface!

Could you as CFG developers please have a look, and maybe make some more competent notes.
Maybe CC to xdg-list of freedesktop.org or even to setup-tool-hackers of GST.

Whitepaper:
http://primates.ximian.com/~miguel/helix-setup-tools.html

Slideshow from GU4DEC 2003:
http://www.gnome.org/projects/gst/stuff/gst-gu4dec-2003/index.html

-Peter

[Config4gnu-developer] Fw: Re: CFG config management (/etc etc.)

[<p.c...@ar...>]

[Hello, i will have a look at this, but maybe you allredy had, and had some interesting thoughts, you might want to share with freedesktop and GNOME about a better way for general configuration.]

----- Original Nachricht ----
Von:     Carlos Perelló Marín <ca...@pe...>
An:      xdg...@fr...
Datum:   08.11.2003 12:45
Betreff: Re: CFG config management (/etc etc.)

El sáb, 08-11-2003 a las 11:58, p.c...@ar... escribió:
> Hello xdg-list,

Hi

> 
> This is a proposal for a config file handling framework.
> Config4gnu or CFG for short is unlike the config "tools" existing
> today.

It's something like the GNOME System Tools' backends

> 
> The system is designed so that just by providing a meta-configuration
> file an application's configuration is fully supported by all CFG
> frontends.  Providing easy configuration in all UIs, scripts or
> programs. In the future these definiton files can be maintained within
> the different software packages so that its central configuration is
> instantly availabe upon installation.

I don't see the beneficies for that kind of "rendering" the settings,
it's just like a normal edit but it does not hide the complex tasks, you
only have key/value entries with some extra information, of course it
lets you add any backend easily but what will you win with that? web
browser GUI?

> 
> So far CFG provides a unified configuration API for all kinds of
> config files on a single machine. Frontends for WWW, GTK, comand line
> (scripts) or programms using the config4gnu API directly all see the
> same "configuration tree". Config4Gnu provides logic/consistency
> checking, activation of changes, "configuration wizards" and more. But
> at all times only the config files under /etc are authoritative and
> are still fully hand editable including the comments.

Just like GNOME System Tools' backend :-P

> 
> The CFG parsers (backends) understand the syntax based on the
> config-file definition and dynamicly generate a xml representation of
> it. If a logic-definition is also available the middlelayer knows wich
> settings are common with other packages, which help texts are
> relevant, how to activate changes, etc. and about wizard and test
> logics.
> 
> 
> CFG is not limiting the personal choice of configuration file style
> for a programer, yet he has all the fancy stuff at hands easily. He
> could even use the Config4Gnu system directliy to parse and generate
> the configuration files for his application.
> 
> According to the two main developers the system is fully functional
> and can edit many config formats.  It supports samba nearly fully. But
> it is not ready for public use yet. For example some dependencies need
> to be cleared.
> 
> Before the project started last year there had been an introductory
> article and discussion about it on freshmeat.
> http://freshmeat.net/articles/view/565/
> 
> To find out more about CFG visit 
> http://config4gnu.sourceforge.net and look into our mailachives.
> Unlike the website states there has also been a tarball released.

To find more about GNOME System Tools visit
http://www.gnome.org/projects/gst

Also, you can see other applications using the backends:
http://knetworkconf.sourceforge.net/

The idea is develop distro independent backends so you have the same
application to configure user accounts, boot loader, etc..

With this mail I'm not telling that config4gnu is not valid, I'm just
showing that it's not alone and I'm trying to show you another
implementation that it's (IMHO) more user friendly.

Cheers.
> 
> -Peter
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Xdg-list mailing list
> Xdg...@fr...
> https://www.redhat.com/mailman/listinfo/xdg-list
-- 
Carlos Perelló Marín
Debian GNU/Linux Sid (PowerPC)
Linux Registered User #121232
mailto:ca...@pe... || mailto:ca...@gn...
http://carlos.pemas.net
Valencia - Spain

Re: [Config4gnu-developer] why not GPL?

[Justin Y. <ju...@sk...>]

On Tue, 4 Nov 2003 14:39:04 +0100 (CET)
p.c...@ar... wrote:

> 
> Hello,
> 
> using the LGPL might hurt our cause. Some party could implement a
> proprietey or distribution specific Programm easily using the CFG API.
> This would not help in improving and promoting the free frontends and
> CFG at all.

They could certainly do this.  I would certainly suggest that its a good idea to make any front ends made by the CFG project be GPL'd, and maybe some other aspects of it as well.  
 
> If a comercial product however only wants to be supported by
> config4gnu there is absolutely no problem, they or others just need to
> release meta-configuration files (preferably GPLed).

If I recall correctly, we weren't worried about supporting other non-GPL apps, we were worried about allowing our configuration API to be used by various applications to *READ* their configuration.  I.e., we have meta-config files to allow users to edit Samba.  Well, in order to accomplish that editing, we also need to support reading the config, and we wanted to eventually open that up so the actual applications didn't have to parse (or validate) their own config files.

Getting them to use CFG to read their config has its advantages:

1) it gets CFG installed on the systems using that app
2) it gives them a good incentive to maintain their meta-config files
3) it gives developers an incentive to create the meta-config files in the first place, since CFG makes reading their config files very easy once they're made. 

So, if we were GPL, then could another application under a less-restrictive license like BSD or the apache license use CFG to read its configuration, or would we be GPL but make a special statement that using it to READ the config for a non-GPL piece of software is OK?  Sure, if its a commercial app, then they can fend for themselves, but if its an "open source" app thats not GPL, I'd like them to be able to use CFG.

I'm open to any suggestions since I don't really understand all of the licensing issues involved.

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

Aw: Re: [Config4gnu-developer] Config GUIs for End Users

[<p.c...@ar...>]

> I'm not sure if this is what you had in mind, but I think Config4GNU could
> handle reading/writing the XF86Config file. Your project would interact
> with
> the configuration file with a simple API provided by Config4GNU.

Shouldn`t he only need to write a meta-config-description for XF86Config and whatever nvidia config, if needed perhaps call some external apps from his "forms" wizard, and be done?
(Provided parsers handlig the needed fileformats exist.)

> I should tell you that Config4GNU is in a state of flux right now... I've
> been doing a lot of thinking and experimenting with different ideas and am
> not sure what direction I would like Config4GNU to go next.

I'am not sure if we allready are in a state to go "next", as long as it is not used by a significant number of people, giving valuable feedback for exactly this decision.

-Peter

[Config4gnu-developer] Re: cfengine and config4gnu

[<p.c...@ar...>]

[Cfengine is designed to handle and propagate configurations in large and inhomogenious computer networks.]


Peter,

thanks for your E-mail. I must confess that I cannot recall having heard of the config4gnu project,
but then I have a short memory for most things! Your project sounds interesting and if it is handled
carefully could be integrated with cfengine. However, the idea of maintaining various file
formats is not really the "cfengine way", so that on a superficial level at least it sounds like
something more traditional than cfengine. 

WHat cfengine could benefit from is a front end that could work as a console monitor and perhaps a
helper application for maintaining the config and any template files. At the moment it sounds like
a system for only generating template files.

I would suggest learning more about cfengine by browsing the website http://www.cfengine.org
and seeing whether you think the methods are compatible. That would be the first step to a
collaboration.

Mark


On  4 Nov, p.c...@ar... wrote:
> 
> Hello everybody,
> 
> i am interested to know if you heard of the config4gnu project and if there might be some interest of hooking it nicely together with cfengine.
> 
> So far Config4gnu provides a unified configuration API for all kinds of config files on a single machine. Frontends for WWW, GTK, comand line (skripts) or programms using the config4gnu API directly all see the same "configuration tree". Config4Gnu provides logic/consistency checking, activation of changes, "configuration wizards" and more. But at all times only the config files under /etc are authoritative and are still fully hand editable including the comments.
> 
> The Config4Gnu parsers (backends) understand the syntax based on a config-file definition and dynamicly generates a xml representation of it. If a logic-definition is also available the middlelayer knows wich settings are common with other packages, which help texts are relevant, how to activate changes, etc. and about wizard and test logics.
> 
> The system is designed so that with two config definition files an application is fully supported, providing easy access for all UIs, scripts or programs. In the future these definiton files can be maintained within the different software packages so that its central configuration is instantly availabe upon installation.
> 
> 
> I see this as the future way to handle configuration for free software. It is not limiting the personal choice of configuration file style for a programer, yet he has all the fancy stuff at hands easily. He could even use the Config4Gnu system directliy to parse and generate the configuration files for his application.
> 
> According to the two main developers the system is fully functional and can edit
> many config formats.  It supports samba nearly fully. But it is not ready for public use yet. For example some dependencies need to be cleared.
> 
> Now my question is if there might be some interest in the cfengine community to work together with this.
> 
> Maybe it would be nice to do configuration changes through the config4gnu system on clients or to use cfengine as backend for config4gnu making a whole lot of machines accassible to all frontends
> 
> To find out more about Config4Gnu please visit http://config4gnu.sourceforge.net and look into our mailachives. Unlike the website states there has also been a tarball released.
> 
> -Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Hel...@gn...
> http://mail.gnu.org/mailman/listinfo/help-cfengine



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Work: +47 22453272            Email:  Mar...@iu...
Fax : +47 22453205            WWW  :  http://www.iu.hio.no/~mark
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: [Config4gnu-developer] Config GUIs for End Users

[Jason L. <jl...@me...>]

I'm not sure if this is what you had in mind, but I think Config4GNU could
handle reading/writing the XF86Config file. Your project would interact with
the configuration file with a simple API provided by Config4GNU.

Which leads me to the question... what programming language does your
project use?

So far we've been doing our configuration file readers and writers
("parsers") in Perl. But it is our goal to make an API that is available in
any programming language.

I should tell you that Config4GNU is in a state of flux right now... I've
been doing a lot of thinking and experimenting with different ideas and am
not sure what direction I would like Config4GNU to go next.

Also, I think the only stuff I did related to XFree configuration was a
prototype "wizard" that displayed a little bit of GUI and not much else.

Jason


>>> csa...@ui... 11/07/03 09:34 AM >>>
Hi,
I just found your Project, and I think i like it very much, because I
was thinking about a project to merge a couple of different Tools for
XFree Konfiguration, that should be integrated into popular Desktop
Environments, like KDE and Gnome.

But now that I know about config4gnu, I'm sure that this is the
preferred platform for such an effort.

I browsed a bit through the mailinglist archive and found a message that
referred to a xfree module in config4gnu, so I think there is something
I can use for my ideas.

And now I'm interested in your Opinion, do you think that config4gnu is
the right choice for an Frontend like this:

http://yanc.sourceforge.net/

yours
Richard Spindler



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Config4gnu-developer mailing list
Con...@li...
https://lists.sourceforge.net/lists/listinfo/config4gnu-developer

Aw: [Config4gnu-developer] Config GUIs for End Users

[<p.c...@ar...>]

----- Original Nachricht ----
Von:     Richard Spindler <csa...@ui...>

> But now that I know about config4gnu, I'm sure that this is the
> preferred platform for such an effort.

You are welcome, it sure is my favourite.

> And now I'm interested in your Opinion, do you think that config4gnu is
> the right choice for an Frontend like this

I am not familiar with nvidia driver config, but the generally CFG concept should absolutely allow it.

> http://yanc.sourceforge.net/

You know, I did not like the german translation of this site very much, talking about a "Fei*dbetriebsystem".

> 
> yours
> Richard Spindler

-Peter

[Config4gnu-developer] Config GUIs for End Users

[Richard S. <csa...@ui...>]

Hi,
I just found your Project, and I think i like it very much, because I
was thinking about a project to merge a couple of different Tools for
XFree Konfiguration, that should be integrated into popular Desktop
Environments, like KDE and Gnome.

But now that I know about config4gnu, I'm sure that this is the
preferred platform for such an effort.

I browsed a bit through the mailinglist archive and found a message that
referred to a xfree module in config4gnu, so I think there is something
I can use for my ideas.

And now I'm interested in your Opinion, do you think that config4gnu is
the right choice for an Frontend like this:

http://yanc.sourceforge.net/

yours
Richard Spindler

[Config4gnu-developer] why not GPL?

[<p.c...@ar...>]

Hello,

using the LGPL might hurt our cause. Some party could implement a proprietey or distribution specific Programm easily using the CFG API. This would not help in improving and promoting the free frontends and CFG at all.

If a comercial product however only wants to be supported by config4gnu there is absolutely no problem, they or others just need to release meta-configuration files (preferably GPLed).

For a broader discussion about this topic see http://www.gnu.org/licenses/why-not-lgpl.html

-Peter

[Config4gnu-developer] API simplification

[Jason L. <jl...@me...>]

Just an update...

I'm still working on Config4GNU when I can (about 2-3 hours a week). I'm
mainly concentrating on parser API--making it a simple and elegant as
possible. Also I hope to untie it from the Xerces XML library.

I haven't committed anything to CVS yet.

My interest lately has been remote access to the configuration data. I think
the most elegant way to do this would be using mechanisms such as SOAP or
CORBA. However, I don't want the parsers to be tied to a particular
mechanism, so I'm separating the CORBA parts I already wrote to be
interfaces to the configuration data.

I've also been thinking that maybe SOAP interfaces should be preferred to
CORBA. At the very least it seems SOAP is a lot more popular...

Jason

Re: [Config4gnu-developer] CORBA, deps, cfg-defs, meta-logic and the establishment

[Justin Y. <ju...@sk...>]

Alright, well, the server I'm supposed to be working on right now is being DOS'd at the moment and I can't even reach it, so I'll offer a very delayed response...   Jason, I'd really like to hear what your feelings are on this too...

> On Saturday 13 September 2003 18:59, Jason Long wrote:
> > CORBA is useful because
> > [...] it allows a backend to run an external program when a new user
> > is created.
> 
> What is the reasonig that config activation should be handled by the
> various  backends?

Well, I think the general idea is that some things can't be accomplished by simply modifying a text file.  A good example of this is adding a firewall rule.  You must run iptables or ipchains to add the rule to the currently running kernel (in addition to saving it someplace so it is reloaded when the server reboots).  

In this type of situation, the configuration can be thought to be stored in 2 places, the running kernel's memory, and in a file to later reload it if necessary.  Regardless of whether it should function in this way, it (any many other systems) does, and we want to try to accommodate it.

> >
> > You also brought up the downside of putting type definition
> > information directly in the parsers rather than in data files.
> > You're right. I think in the general case type definitions (such as
> > what properties are allowed where and what type of values different
> > properties take) should be in data files (using XML). On the other
> > hand, with the huge variety of different configuration formats,
> > we'll constantly be faced with configuration files that have rules
> > that cannot be expressed in the data format we've chosen. So we'll
> > end up modifying the XML syntax used in the type definition files
> > and creating additional logic in the middle layer to handle the
> > additional complexity of certain configuration files.
> >
> > All this to say, I think the ability to override type definitions
> > programmatically could be useful. By making the parser layer
> > responsible for providing type definitions to the rest of the
> > system, the parser layer in the basic case can read from an XML type
> > definition file, and in the special cases, can do something
> > different.
> 
> Does this mean a parser won't be constanty faced with new
> configuration files and won't need modifications. If so won't there be
> a need for a huge variety of specificaly tailored CFG Backend Parsers?
> 
> IMHO from time to time there will allways be a need to introduce a new
> feature into the definition-file-format and make the CFG system aware
> of it. A  implementation solely into a specific backend might not help
> the rest of the system.

Agreed, its a mess.  What I had been doing with the parsers was separating the syntax of the file from its semantics.  

A parser was written to handle the syntax, i.e., an INI-style config file.  That parser understands nothing more than INI files, and it doesn't care whether you set your IP address to -1000, or that your configuration is invalid or makes no sense.  

When the parser discovers a configuration directive, it tries to add that directive to the XML document.  During that add, another layer handles TRANSLATION (i.e., false = 0 = no = off = Off = No = False, writeable means the same as writable, etc.).  At this point, a meaningful XML representation of the configuration is available for use by other layers of CFG.  

As a side note, its pretty trivial as to whether translation is done in the parser layer or in the middle layer, as its just a matter of where you separate the 2 layers.  It just should be configurable.  Right now its in the perl itself, but it really should be in XML.   

So, using this approach, if someone comes along with a new config file format, then we have to write another syntax parser, which isn't often.  If they come along with a semantically different file (which happens all the time, each application has its own directives, etc.), all you have to do is write any translations.  Translations are really only necessary to handle the weird cases where configuration directives has synonyms, antonyms, etc.

IMHO, this approach is extremely useful, because when you're past this point, you really have as much data in the XML as possible.  The only thing lacking is logic which says under what situations a directive is valid, how to activate a certain XML node of configuration, etc.   However, this is by design.

In a world where everyone stored their config in properly designed XML (NOTE: I don't suggest we should really do that!), the parser layer is completely unnecessary.  You would just read in the XML file, and thats it, off to the middle layer.

The problem is, configuration isn't just stored in XML, isn't always stored just in files, and sometimes is stored in multiple places which must all be updated.

Additionally, most applications/servers aren't written to accept all configuration directives everywhere.  Some directives are mutually exclusive, some are only valid if other directives have a particular value, etc.  

If you store these types of things in the configuration XML itself, or even in the parser, then you're going to have way too many copies of the logic to handle that configuration (several slightly different logic routines per configuration file! yuck!).  


The quote I want to specifically address from Jason's original email is: 
> > So we'll
> > end up modifying the XML syntax used in the type definition files
> > and creating additional logic in the middle layer to handle the
> > additional complexity of certain configuration files.

Exactly.  That is by design.  The logic goes in the middle layer, which will be able to validate data coming in from either the parsers (which get it from the config files), or the front ends (which get it from the user).  This validation will be according to complex rules which we can define in XML.  That logic does not belong in either the parser layer or in the front end.  

If we don't put it in the middle layer, then you may as well throw up your hands and use an existing tool, because that is what makes this project unique.  Sure it uses XML, but thats just to make certain things simpler.


As a hypothetical example, say our parser only supported apache 1.3.x's configuration.  It had all the necessary rules to say what directives can go where, what directives exist, etc.  The logic to cross-check that the configuration makes sense is all working.

To add support for apache 2.x, what would we have to do?  Is the parser different?  Nope, still same format, it still just reads it & passes it along, without knowing much about it.  Is the front end different?  Nope, it still just reads XML & input from the user, without really knowing whats going on.  The only thing we'd change is the logic in the middle layer, and probably only in an XML file or two, to remove & add a few directives, and change what is valid for a few others.  

I don't understand what is so complicated about that sort of change that would warrant trying to avoid it.  Jason, are you just referring to the constant addition of logic that we'd need to incorporate to validate a configuration?  I think there are a finite number of the types of checks we'd need to use, and we could just assign them to the necessary types in the type definition file.  I don't think adding that sort of thing would be very difficult.



> Reading about your involvement in this project I hope you are
> interested in the thoughts of a third party (me), so I try to help the
> project with the following thoughts for discussion:
> 
> A) Configuraion representation in CORBA objects instead of XML.
> 
> - OK, if it makes things significatily easier or more elegant. But
> won't it add unfortunate dependencies? Thinking about a linux
> distribution installer or small embedded systems. I think in order to
> establish a configuration system into a widely used de-facto standard
> the core has to be as simple and independent as possible. (At the same
> time so modular that it is capable to provide all the nice full blown
> wiz-bang features possible) In fact that is why config4gnu catched my
> eye.

My main objection to the idea of corba is still that we have to store the configuration in some sort of hierarchical tree with "objects" of some type that are defined somewhere... right?  So why re-invent XML?  For debugging (and serialization/caching), we'd probably end up exporting the stuff to XML anyway... so why not just use it from the start?


> B) Adding logic to the parsers ecceeding that of generating a generic
> CFG representation from a specific file with the help of a
> config-definition-file?
> 
> Now this just doesn't sound right to me. Having read the CFG article
> from an admin point of view I was thinking the basic step in order to
> get CFG support for an application is to provide a
> config-file-description. The Middlelayer then finds this description
> file and can call the appropriate parser with it to get the generic
> representation. Parsers are kept as generic as they can be to lower
> the need to write separate new ones. With a config-file-description it
> would allready be possible for all front-ends to manipulate the
> generic configuration representation on a fine grained level. The
> config-file-descriptions also provide good defaults values that can
> also be references to other parts of the system wide configuration (in
> its CFG representation) (i.e. use HTTP_Proxies setting (from
> /etc/profile ?)as default in other programs). And if a front-end
> changes a setting the *middlelayer* knows from the
> config-definition-file what actions to take in order to aktivate the
> changes (something like "ActivationCommand is killall -HUP serviceXYZ"
> or "[init.directory]/serviceXYZ reload").
> 
> The next level of CFG support would include providing
> logic-definition-files. Which might define meta-variables, wizard
> hierachies of questions and consequenses and other constructs like "If
> bind is installed the meta-variable DNS-Server goes into forwarders
> for bind and /etc/resolv.conf will point to the localhost:[port
> configured for bind]". In some cases the logic-definition could also
> point to some specific external implementations (binary or script of
> choice) to do for example some tests of a just configured service and
> get some result code.
> 
> (Hmmm. Sounds a little like a system of generic shell scripts (like
> the boot up procedures or pcmcia/hotplug config scripts) to me.)

Exactly how I'd picture it.  I'd suggest there would be a library of generic checking & activation routines, which would be as generic as possible.  Any sort of small script would work nicely.  The only exception would be if it has to run over & over & over, in which case we could optimize it by building those routines in C++ or something so we could just load a library & get it done faster. 

> Support of user modes or profiles (beginner/expert) in the middle
> layer might also be crucial for wide spread use. The most simple
> approach is maybe if a front-end requests the configuration for a
> "beginner" it will only be given the part of the
> configuration-representation and logic labeled as "settings needed
> even from beginners". The rest is set to default values.

That would be a good way to do it.  Each configuration directive could have a "difficulty rating" of some sort.

> If a logic is defined it would be nice if Middlelayer could import it
> (front-end implementation independantly) and somehow all front-ends
> will than be able to run the wizard logic and interact with external
> apps (through the middlelayer)

Actually, we've basically got wizard support and most of that stuff.  Its just the fancier validation and activation thru external systems (and a handful of other more obscure things I won't get into) that haven't yet been implemented.

> Hmmm. I know I don't know! - How this Gui/Frontend independent
> separated logic can be implemented and to a large extend not be
> hardcoded into the middlelayer. I agree it would be a good idea to
> discuss this with some programmers like those on freedesktop.org.

The GUI is really kept as an XML editor.  Each configuration file or section is a separate entity, and when the GUI tries to add something to it, the middle layer either says OK or says no, or provides a list of available things to add.  This, IMHO, we've already got working pretty well in our code.

> Another thing I think is important in order to gain wide acceptance is
> to allow the frontends to show where in the /etc system the dispayed
> settings will actually be manipulated. Otherwise it might be too much
> of a "blackbox" experience. This way "Beginner mode" users won't be
> locked in and can learn from references. And by showing reference it
> can be a great tool even for the experienced sysadmin to explore some
> areas of configuration files he is not yet so intimate with.

We've thought about doing that, and it'd be pretty trivial to implement.  It would certainly give some insight into what the tool is doing.  It might also be useful for scripts to be told by the command line interface "Ok, I set the config how you asked it, I changed file A & file B", so that the script could perform some operation on those files (can't think of anything specific off hand).

> 
> PPS:
> I agree with Justin that it would be beneficial to levarage what is
> there for samba and get the system out to others. BTW how was the
> response to the Slashdot article, maybe it would make sense to write a
> one year follow up.

The response was OK.  We got a lot of people saying that the whole idea was stupid, pointless, already done, or "real" linux users don't need it.  Most of the rest didn't really understand it I don't think (or try to).  There were definitely some though, who really liked the idea, and that was encouraging.  I feel like if we're going to try to do another announcement on a big site like freshmeat or slashdot that we should have usable, stable code capable of configuring at least one major system (samba).  We're really not that far from that goal, well, assuming one or both of us have the time to code it.


I really appreciate your feedback.  Keep the suggestions coming.

Justin

-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] CORBA, deps, cfg-defs, meta-logic and the establishment

[<p.c...@ar...>]

Hi!

I wonder a little about the discussion going on about were to handle configuration-definitions after having read the CFG article.

On Saturday 13 September 2003 18:59, Jason Long wrote:
> CORBA is useful because
> [...] it allows a backend to run an external program when a new user is created.

What is the reasonig that config activation should be handled by the various  backends?

>
> You also brought up the downside of putting type definition information
> directly in the parsers rather than in data files. You're right. I think in
> the general case type definitions (such as what properties are allowed
> where and what type of values different properties take) should be in data
> files (using XML). On the other hand, with the huge variety of different
> configuration formats, we'll constantly be faced with configuration files
> that have rules that cannot be expressed in the data format we've chosen.
> So we'll end up modifying the XML syntax used in the type definition files
> and creating additional logic in the middle layer to handle the additional
> complexity of certain configuration files.
>
> All this to say, I think the ability to override type definitions
> programmatically could be useful. By making the parser layer responsible
> for providing type definitions to the rest of the system, the parser layer
> in the basic case can read from an XML type definition file, and in the
> special cases, can do something different.

Does this mean a parser won't be constanty faced with new configuration files and won't need modifications. If so won't there be a need for a huge variety of specificaly tailored CFG Backend Parsers?

IMHO from time to time there will allways be a need to introduce a new feature into the definition-file-format and make the CFG system aware of it. A  implementation solely into a specific backend might not help the rest of the system.


Reading about your involvement in this project I hope you are interested in the thoughts of a third party (me), so I try to help the project with the following thoughts for discussion:

A) Configuraion representation in CORBA objects instead of XML.

- OK, if it makes things significatily easier or more elegant. But won't it add unfortunate dependencies? Thinking about a linux distribution installer or small embedded systems. I think in order to establish a configuration system into a widely used de-facto standard the core has to be as simple and independent as possible. (At the same time so modular that it is capable to provide all the nice full blown wiz-bang features possible)
In fact that is why config4gnu catched my eye.




B) Adding logic to the parsers ecceeding that of generating a generic CFG representation from a specific file with the help of a config-definition-file?

Now this just doesn't sound right to me. Having read the CFG article from an admin point of view I was thinking the basic step in order to get CFG support for an application is to provide a config-file-description. The Middlelayer then finds this description file and can call the appropriate parser with it to get the generic representation. Parsers are kept as generic as they can be to lower the need to write separate new ones.
With a config-file-description it would allready be possible for all front-ends to manipulate the generic configuration representation on a fine grained level. The config-file-descriptions also provide good defaults values that can also be references to other parts of the system wide configuration (in its CFG representation) (i.e. use HTTP_Proxies setting (from /etc/profile ?)as default in other programs). And if a front-end changes a setting the *middlelayer* knows from the config-definition-file what actions to take in order to aktivate the changes (something like "ActivationCommand is killall -HUP serviceXYZ" or "[init.directory]/serviceXYZ reload").

The next level of CFG support would include providing logic-definition-files. Which might define meta-variables, wizard hierachies of questions and consequenses and other constructs like "If bind is installed the meta-variable DNS-Server goes into forwarders for bind and /etc/resolv.conf will point to the localhost:[port configured for bind]". In some cases the logic-definition could also point to some specific external implementations (binary or script of choice) to do for example some tests of a just configured service and get some result code.

(Hmmm. Sounds a little like a system of generic shell scripts (like the boot up procedures or pcmcia/hotplug config scripts) to me.)

Support of user modes or profiles (beginner/expert) in the middle layer might also be crucial for wide spread use. The most simple approach is maybe if a front-end requests the configuration for a "beginner" it will only be given the part of the configuration-representation and logic labeled as "settings needed even from beginners". The rest is set to default values.

If a logic is defined it would be nice if Middlelayer could import it (front-end implementation independantly) and somehow all front-ends will than be able to run the wizard logic and interact with external apps (through the middlelayer)

Hmmm. I know I don't know! - How this Gui/Frontend independent separated logic can be implemented and to a large extend not be hardcoded into the middlelayer. I agree it would be a good idea to discuss this with some programmers like those on freedesktop.org.

However I think it is very crucial to keep it unix-like and modular.


-Peter



PS:
Another thing I think is important in order to gain wide acceptance is to allow the frontends to show where in the /etc system the dispayed settings will actually be manipulated. Otherwise it might be too much of a "blackbox" experience. This way "Beginner mode" users won't be locked in and can learn from references. And by showing reference it can be a great tool even for the experienced sysadmin to explore some areas of configuration files he is not yet so intimate with.


PPS:
I agree with Justin that it would be beneficial to levarage what is there for samba and get the system out to others.
BTW how was the response to the Slashdot article, maybe it would make sense to write a one year follow up.

[Config4gnu-developer] CORBA, deps, cfg-defs, meta-logic and the establishment

[<p.c...@ar...>]

Hi!

I wonder a little about the discussion going on about were to handle configuration-definitions after having read the CFG article.

On Saturday 13 September 2003 18:59, Jason Long wrote:
> CORBA is useful because
> [...] it allows a backend to run an external program when a new user is created.

What is the reasonig that config activation should be handled by the various  backends?

>
> You also brought up the downside of putting type definition information
> directly in the parsers rather than in data files. You're right. I think in
> the general case type definitions (such as what properties are allowed
> where and what type of values different properties take) should be in data
> files (using XML). On the other hand, with the huge variety of different
> configuration formats, we'll constantly be faced with configuration files
> that have rules that cannot be expressed in the data format we've chosen.
> So we'll end up modifying the XML syntax used in the type definition files
> and creating additional logic in the middle layer to handle the additional
> complexity of certain configuration files.
>
> All this to say, I think the ability to override type definitions
> programmatically could be useful. By making the parser layer responsible
> for providing type definitions to the rest of the system, the parser layer
> in the basic case can read from an XML type definition file, and in the
> special cases, can do something different.

Does this mean a parser won't be constanty faced with new configuration files and won't need modifications. If so won't there be a need for a huge variety of specificaly tailored CFG Backend Parsers?

IMHO from time to time there will allways be a need to introduce a new feature into the definition-file-format and make the CFG system aware of it. A  implementation solely into a specific backend might not help the rest of the system.


Reading about your involvement in this project I hope you are interested in the thoughts of a third party (me), so I try to help the project with the following thoughts for discussion:

A) Configuraion representation in CORBA objects instead of XML.

- OK, if it makes things significatily easier or more elegant. But won't it add unfortunate dependencies? Thinking about a linux distribution installer or small embedded systems. I think in order to establish a configuration system into a widely used de-facto standard the core has to be as simple and independent as possible. (At the same time so modular that it is capable to provide all the nice full blown wiz-bang features possible)
In fact that is why config4gnu catched my eye.




B) Adding logic to the parsers ecceeding that of generating a generic CFG representation from a specific file with the help of a config-definition-file?

Now this just doesn't sound right to me. Having read the CFG article from an admin point of view I was thinking the basic step in order to get CFG support for an application is to provide a config-file-description. The Middlelayer then finds this description file and can call the appropriate parser with it to get the generic representation. Parsers are kept as generic as they can be to lower the need to write separate new ones.
With a config-file-description it would allready be possible for all front-ends to manipulate the generic configuration representation on a fine grained level. The config-file-descriptions also provide good defaults values that can also be references to other parts of the system wide configuration (in its CFG representation) (i.e. use HTTP_Proxies setting (from /etc/profile ?)as default in other programs). And if a front-end changes a setting the *middlelayer* knows from the config-definition-file what actions to take in order to aktivate the changes (something like "ActivationCommand is killall -HUP serviceXYZ" or "[init.directory]/serviceXYZ reload").

The next level of CFG support would include providing logic-definition-files. Which might define meta-variables, wizard hierachies of questions and consequenses and other constructs like "If bind is installed the meta-variable DNS-Server goes into forwarders for bind and /etc/resolv.conf will point to the localhost:[port configured for bind]". In some cases the logic-definition could also point to some specific external implementations (binary or script of choice) to do for example some tests of a just configured service and get some result code.

(Hmmm. Sounds a little like a system of generic shell scripts (like the boot up procedures or pcmcia/hotplug config scripts) to me.)

Support of user modes or profiles (beginner/expert) in the middle layer might also be crucial for wide spread use. The most simple approach is maybe if a front-end requests the configuration for a "beginner" it will only be given the part of the configuration-representation and logic labeled as "settings needed even from beginners". The rest is set to default values.

If a logic is defined it would be nice if Middlelayer could import it (front-end implementation independantly) and somehow all front-ends will than be able to run the wizard logic and interact with external apps (through the middlelayer)

Hmmm. I know I don't know! - How this Gui/Frontend independent separated logic can be implemented and to a large extend not be hardcoded into the middlelayer. I agree it would be a good idea to discuss this with some programmers like those on freedesktop.org.

However I think it is very crucial to keep it unix-like and modular.


-Peter



PS:
Another thing I think is important in order to gain wide acceptance is to allow the frontends to show where in the /etc system the dispayed settings will actually be manipulated. Otherwise it might be too much of a "blackbox" experience. This way "Beginner mode" users won't be locked in and can learn from references. And by showing reference it can be a great tool even for the experienced sysadmin to explore some areas of configuration files he is not yet so intimate with.


PPS:
I agree with Justin that it would be beneficial to levarage what is there for samba and get the system out to others.
BTW how was the response to the Slashdot article, maybe it would make sense to write a one year follow up.

[Config4gnu-developer] Hosting at freedesktop.org?

[Damien U. <car...@op...>]

Hey,

Have you guys thought of getting your project hosted at freedesktop.org ? I 
know it's not a desktop project, per say, but there are other projects on 
there that are looking at closer integration between the UI level and the 
underlying OS - such as DBUS and HAL (making process communication/ device 
management easier)..

This may give your ideas much needed exposure. IMO, a sane *common* 
configuration system that makes it relatively simple to provide a UI for is 
extremely important to furthering Open Source operating systems - not just 
for computer novices, but for everybody.

Just a thought,

Damien.

Re: [Config4gnu-developer] Using CORBA for configuration

[Jason L. <jl...@me...>]

First off, let me say I have a tendency to want to constantly redesign
programs that I've written, because I always feel there's a better way to do
things. So I welcome criticism. If I constantly redesign things we won't
ever get anything done :).

I'm going to take the diagram you made and modify it to show what I'm
thinking...

Parsers/Backend
      |
      | CORBA
      |
Middle Layer
      |
      | CFG API
      |
Various front ends


Basically this replaces the idea of generating XML representations of the
configuration and passing them back and forth. The parser reads a
configuration file, generates an in-memory data structure representing it,
and makes the data available for reading and writing through CORBA
interfaces.

CORBA is useful because it allows the parsers to be separate processes (and
different programming languages) from the front-end. Yet, at the same time,
the backends are fully involved with changes being made to the
configuration. This allows, for instance, a "User & Groups" backend to run
an external program when a new user is created.

You also brought up the downside of putting type definition information
directly in the parsers rather than in data files. You're right. I think in
the general case type definitions (such as what properties are allowed where
and what type of values different properties take) should be in data files
(using XML). On the other hand, with the huge variety of different
configuration formats, we'll constantly be faced with configuration files
that have rules that cannot be expressed in the data format we've chosen. So
we'll end up modifying the XML syntax used in the type definition files and
creating additional logic in the middle layer to handle the additional
complexity of certain configuration files.

All this to say, I think the ability to override type definitions
programmatically could be useful. By making the parser layer responsible for
providing type definitions to the rest of the system, the parser layer in
the basic case can read from an XML type definition file, and in the special
cases, can do something different.

Jason

Re: [Config4gnu-developer] Using CORBA for configuration

[Justin Y. <ju...@sk...>]

OK, I'm going to come out of the shadows & finally post something.  I'd like to first respond directly to your post and then secondly give some more of my thoughts, which may both be grossly incorrect.

First, CORBA has a lot of benefits, which you mention, and it handles a lot of things for us.  It may very well be easier for a front end to interact with the rest of the architecture thru corba.  I agree it would be a good direction to explore.  

However, I'm not so sure I agree w/ 2 sortof side-effects you mentioned.

1) removing XML definition files.

This, I think, is not a good idea.  A critical part of the architecture involves the fact that front and back ends are interchangeable.  If the actual "data" about the configuration file (apart from its lexical structure) is stored in the perl modules, then they are only extensible if you want to write in perl, AND you can only modify them or write your own similar one easily if you write in perl.  

In addition to the data being stored in the wrong place (in the "program", which is what I think we'd like to avoid as much as possible), the logic that handles the data would also exist in the wrong place (the parsers).  This belongs in the middle layer, and is perhaps one of the middle layer's most important functions.  The middle layer, in essence, is what "knows" *about* everything, it just doesn't know what to *do* with anything, which is what the front and back ends' purposes are.

I guess that pretty much sums up my stance on that.  I'd like to hear an argument for putting them in perl, but it just seems like a "bad idea", and a departure from the type of architecture the CFG is intended to have.

2) CORBA for communication between middle layer and the back ends.  Maybe I'm misunderstanding you, but don't think CORBA is a good candidate for internal communication.  Too much overhead and not much benefit.  On the other hand, writing a front end to our system that speaks CORBA and writing a "front end to that front end", might be a very good idea.  I'd hate to force everyone who writes a front end for CFG to use CORBA though, again seems like it limits flexibility.  So I could see CORBA being used with some benefit like so, with the things to the right of the |'s being the protocol used for communication

Parsers/Backend
      |
      | XML
      |
Middle Layer
      |
      | CFG API
      |
CORBA FRONT END
      |
      | CORBA
      |
Some GUI that talks CORBA


Maybe thats what you meant in the first place though.



So for other thoughts on the project:

1) I'm really not finding much time to work on it (as you can tell), but I really *want* to work on it (and will when I can), so keep me in the loop.

2) I don't know how much you've changed it since May, but what I really think we need to do is leverage the support we've got for Samba to help get CFG out to more people (even if its just developers).  I'd like to get in touch w/ some Samba people and explain what we've got, and that we'd like to work w/ them to clean up and lose ends in reading and understanding the config files, and also come out with something usable enough to be a stable release, perhaps light on fancy features, but usable for most everything w/ Samba, even if we've just got the GTK interface.

3) For it not to die, we need to figure out where to strategically focus our efforts to a) accomplish the most toward getting something useful out of our time spent, and b) get some more support.  It will be real hard to get everything done w/ just us, especially w/ us both working.


Justin

On Tue, 09 Sep 2003 07:34:26 -0400
"Jason Long" <jl...@me...> wrote:

> In a recent email I mentioned I've been doing some research into using
> CORBA for configuration tasks. Basically I'm using CORBA interfaces
> instead of XML for passing information between the frontend and the
> backend.
> 
> I've found this direction to be pretty fruitful. First of all, using
> CORBA means it is _much_ easier to do things like execute a command
> when configuration changes, or give an option to "restart service" to
> the user. This is because the backend stays alive as long as the
> configuration is being used; it holds the configuration in memory and
> is triggered whenever a change is requested to the configuration.
> 
> A second benefit I recently thought of is that we could do away with
> the XML definition files. Instead, we would make the parsers aware of
> what properties are allowed where, what types of values they can have,
> etc. and the frontend would query the backend for this information.
> Again, this is possible because the backend stays active as long as
> the configuration is being edited.
> 
> The parsers will still be very object oriented, and easy to extend.
> For those interested in code, I'll give an example. In this example, I
> provide a Property interface for Samba Boolean properties.
> 
> package Samba::BooleanProperty;
> @ISA = ('Ini::Property');
> 
> @ALLOWED_VALUES_TRUE = ('true', 'yes', '1');
> @ALLOWED_VALUES_FALSE = ('false', 'no', '0');
> 
> sub _get_value
> {
>     my $self = shift;
> 	
> 	if (grep {$_ eq lc($self->{value})} @ALLOWED_VALUES_TRUE)
> 	{
> 		return $ALLOWED_VALUES_TRUE[0];
> 	}
> 	elsif (grep {$_ eq lc($self->{value})} @ALLOWED_VALUES_FALSE)
> 	{
> 		return $ALLOWED_VALUES_FALSE[0];
> 	}
>     return $self->{value};
> }
> 
> sub setValue
> {
> 	my $self = shift;
> 	my $newvalue = shift;
> 
> 	if ((grep {$_ eq lc($newvalue)} @ALLOWED_VALUES_TRUE) ||
> 	    (grep {$_ eq lc($newvalue)} @ALLOWED_VALUES_FALSE))
> 	{
> 		$self->{value} = $newvalue;
> 	}
> 	else
> 	{
> 		throw CFG::Property::InvalidValue
> 			msg => 'Valid values are yes/no, true/false, 1/0';
> 	}
> }
> 
> Peter, it's good to hear from you. Thanks for your comments. You
> mention that you cannot help with code, so I hope we can find another
> way for you to help.
> 
> Keep in touch,
> 
> Jason Long
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Config4gnu-developer mailing list
> Con...@li...
> https://lists.sourceforge.net/lists/listinfo/config4gnu-developer
> 
> 


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com

[Config4gnu-developer] Using CORBA for configuration

[Jason L. <jl...@me...>]

In a recent email I mentioned I've been doing some research into using CORBA
for configuration tasks. Basically I'm using CORBA interfaces instead of XML
for passing information between the frontend and the backend.

I've found this direction to be pretty fruitful. First of all, using CORBA
means it is _much_ easier to do things like execute a command when
configuration changes, or give an option to "restart service" to the user.
This is because the backend stays alive as long as the configuration is
being used; it holds the configuration in memory and is triggered whenever a
change is requested to the configuration.

A second benefit I recently thought of is that we could do away with the XML
definition files. Instead, we would make the parsers aware of what
properties are allowed where, what types of values they can have, etc. and
the frontend would query the backend for this information. Again, this is
possible because the backend stays active as long as the configuration is
being edited.

The parsers will still be very object oriented, and easy to extend. For
those interested in code, I'll give an example. In this example, I provide a
Property interface for Samba Boolean properties.

package Samba::BooleanProperty;
@ISA = ('Ini::Property');

@ALLOWED_VALUES_TRUE = ('true', 'yes', '1');
@ALLOWED_VALUES_FALSE = ('false', 'no', '0');

sub _get_value
{
    my $self = shift;
	
	if (grep {$_ eq lc($self->{value})} @ALLOWED_VALUES_TRUE)
	{
		return $ALLOWED_VALUES_TRUE[0];
	}
	elsif (grep {$_ eq lc($self->{value})} @ALLOWED_VALUES_FALSE)
	{
		return $ALLOWED_VALUES_FALSE[0];
	}
    return $self->{value};
}

sub setValue
{
	my $self = shift;
	my $newvalue = shift;

	if ((grep {$_ eq lc($newvalue)} @ALLOWED_VALUES_TRUE) ||
	    (grep {$_ eq lc($newvalue)} @ALLOWED_VALUES_FALSE))
	{
		$self->{value} = $newvalue;
	}
	else
	{
		throw CFG::Property::InvalidValue
			msg => 'Valid values are yes/no, true/false, 1/0';
	}
}

Peter, it's good to hear from you. Thanks for your comments. You mention
that you cannot help with code, so I hope we can find another way for you to
help.

Keep in touch,

Jason Long

[Config4gnu-developer] intersting reading

[<p.c...@ar...>]

Well, I came accross http://www.cfengine.org and found it might be an intersting reading.
It is a configuration engine that scales for large networks. Google did not come up with somthing for "config4gnu +cfengine" so I thought maybe this is also new for you.

Also some other good thoughts about the issue:
http://cbbrowne.com/info/multiplexor.html#AEN23645 (Section 4.1 !)

[Config4gnu-developer] config/wizard definitons format, ext. apps

[<p.c...@ar...>]

Hello silent list!

Yes, I too was kind of tracking this interesting project, I think it has the potential to make a great impact!
Thanks for the news Jason and hey, congrats Justin!

First I was wondering what those "some more advanced features we want to incorporate before we dub [CFG] as ready for public use" are, that Justin wrote about a while ago on the list.

Then I thought maybe I'll try to make a config descripion file and test it, since I  can not help with code.

I searched some of your docs and got thinking. I read about the needed possibility to execute external programms for some config tasks (adduser?). Would it also be possible to execute an external "hardware test/search" application to find possible config settings or check devices from within a "config wizard"?
So that for example a quick self test on a configured digicam can be done or there can be a drop-down list with available interfaces to bind to (eth0 (192.168.1.1), lo (127.0.0.1) etc.) Well, ok this info might allready be in another part of the config data, but to give an idea.

-Peter

[Config4gnu-developer] Project slow-down and research into WBEM and CORBA

[Jason L. <jl...@me...>]

This is a news item I am posting to Sourceforge...

For those tracking the Config4GNU project, you may have been disappointed in
the past few months as there has been no news and very little traffic on the
mailing list. This can mainly be attributed to the project leaders--Jason
Long and Justin Yackoski--finishing their classes and graduating. Justin
also got married in June (congratulations to him!) so that's been keeping
him busy.

Meanwhile, I, Jason, have been focusing on doing some research into some new
directions and ideas. A few weeks ago I announced on the mailing list my
intention of looking into WBEM for configuration. WBEM (Web-Based Enterprise
Management) is a set of standards for managing enterprise networks. After
some initial difficulties, I did figure out how to write an OpenWBEM
provider in C++. In addition, I feel like I'm starting to have some
understanding of what WBEM can do for configuration, although I will not go
into detail here.

More recently I've been experimenting with joining configuration tasks with
CORBA. This requires writing some interface definitions for configuration
tasks, and then implementing those interfaces for different types of
configurations. Clients can be written in any language that has CORBA
bindings, and they will be able to interact with configuration through the
CORBA interfaces. This approach basically substitutes Config4GNU's current
approach of passing XML representations between the client and the parsers.

[Config4gnu-developer] looking into WBEM

[Jason L. <jl...@me...>]

Well over the past few months I've been distracted from Config4GNU, but I
hope to continue working with Config4GNU.

It was suggested a few months ago that I look into WBEM (web based
enterprise management). I'm finally getting around to doing that. It's
basically an improvement over SNMP, I think. It defines a pretty extensible
object model and some protocols, which I think could be used for
configuration.

Two technologies I'm planning to investigate in more detail are OpenWBEM and
CIMNavigator. Their URLs are:

http://openwbem.sourceforge.net/
http://www.cimnavigator.com/home.html

If all goes well I'll try some prototypes and let you know how it goes.

Information about WBEM and the authoring working group DMTP can be found
here:

http://www.dmtf.org/standards/index.php


Jason Long