config4gnu-developer — Config4GNU developers list

[Config4gnu-developer] Sample config files

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

I was thinking it would be nice to distribute some sample configuration
files with the Config4GNU package. I want this so that users can try out
Config4GNU without needing to have working installs of Samba, Apache, etc.
In addition, they wouldn't need to worry about Config4GNU trashing their
existing configuration files.

Any volunteers for collecting some sample config files? We should have at
least: Samba, Apache, PHP, BIND, DHCP server, Postfix (or insert favorite
mail server here), SSHD, passwd & group files, ...etc...

Jason

Re: [Config4gnu-developer] why not GPL?

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

>
> There are still some issues if the vendors think that their meta-data is
> some secret or whatever.  Does anyone have any ideas on how to get around
> this or find some middle ground so the meta-data is published in some way
> but vendors are happy?

I don't understand. Let's say Novell distributes "Novell Directory Services" 
for use on some distros that use CFG. Their installer copies the meta-data 
config file into the correct location and does whatever else to integrate 
into CFG. Now, this XML file is a text file, so anybody can change it if they 
really want to. It only makes sense for Novell to distribute it, because it's 
only relevant to Novell Directory Services. I don't know why the hell anyone 
would claim copyright on a configuration file and put it under some sort of 
license.

The only thing the proprietary vendors care about is the source code for their 
application. Why even bother thinking about licenses for the meta data files? 
I don't see why anyone cares.

Damien

>
> Justin

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

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

This is some great discussion, thanks to everyone for your thoughts on CFG.  I just want to clarify a few things regarding CFG's design (most, but not all, of the things I'll be mentioning are currently working)

On Mon, 10 Nov 2003 14:00:42 +0100 (CET)
p.c...@ar... wrote:

> 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 inspired to have a
> nice framework for flexible and simplified handling of any /etc
> configuration, systemwide.

We had looked at GST/Helix Setup Tools about a year ago, and decided to use a slightly different approach.  At the time it also appeared to not be in active development.  I think there's a lot of potential for collaboration between the two groups.  In fact, I think that GST could comfortably sit on top of CFG by developing a very nice GTK frontend and contributing/merging the rest with CFG's other layers.  Not that CFG is necessarily better, I'm just saying it would not be hard to do.

Anyway, CFG was intended to edit ANY configuration.  We initially focused on stuff in /etc for Samba, Apache, etc. because we were hoping to get the developers of those applications to help add support for them.  This was mainly because things like Gnome have more user-friendly (context-sensitive help, nice look, etc.) config tools than those apps, so we thought there would be more interest.  We were wrong, or we didn't get the word out properly. :) 

Its main intent is to create 3 layers with separate purposes

bottom: parsing various config formats into generic XML

middle: transforming generic XML into more specific XML, adding
        extra information (documentation, defaults, rules, etc.)
        all special XML elements are sub-classes of generic XML

top:    main UIs edit generic XML, and also know how to ask for
        extra information (defaults, context-sensitive help, etc.)

I believe that GST splits some of our middle layer's functionality into the top & bottom layer.  I think a middle layer is important here so that both the bottom & top layers can be more generic, so that in most
cases to get a new app supported by CFG, you just add support in the
middle layer (via an XML meta-data document).

I'm sure there are advantages and disadvantages to this approach.

> > > 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
> 
> Yes just having keys and values is not really user friendly, that is
> why CFG is not limited to them and has also wizards and forms, however
> the keys and values are interesting for the applications themself if
> they want to read their configuration through the config4gnu (allready
> validated and with defaults)

CFG does think that most configuration is essentially key value pairs (lists & other things that can be represented in XML are supported too), but that doesn't mean the user edits key/value pairs ala the windows registry.  

The bottom layer converts config data into XML key/value pairs, the middle layer says that a key for say GTK's config named "background color" stores a "color" type of value and validates that a rogue user/GUI doesn't try to set it to an IP address, and the top layer is responsible for rendering a nice color wheel widget to pick a color when it is told a particular key stores a color value.  

This allows the top layers to be very generic GUIs whose layout is modified by the XML meta-data files describing the keys, and forms & wizards to display them.  Last I checked, GST had somewhat hard-coded GUIs that looked for specific config data.  Is this still the case?

> 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 Interfaces (KDE, XFCE, etc.) would also need new modules?

I think so, but I bet someone from GST could explain this better.
 
> The approach in CFG is to have the configuration logic be within a
> middlelayer, so every Frontend that queries CFG can configure anything
> the middlelayer 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 help for a
> service without nessecarily knowing anything about the service itself.
> 
> Another nice thing is, that nothing in the middlelayer or the backends
> is hardcoded 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)

This is exactly what our primary goal is.  You only add/change support in *1* place.  We felt that changing things in more than one place was a waste of work, and we wanted a tool that kept all the very specific meta-data in 1 place.

> Here I have copied some notes from Damien Uern who was also looking
> into GST and CFG. Trying to benefit both he writes:
> 
> ----------
> > [GST] 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!). 
> 
> I do not understand, how would CFG try to change the programs?

Me either.  CFG doesn't make any attempt to change existing programs.  This is a fairly common misconception.  CFG is purely an abstraction layer that converts existing config data into an easier to work with standard XML format, and then converts it back again when you save your changes.  If we didn't tell you on our website, nothing would know that it did this or that it uses XML, but we mention it repeatedly because it is what makes CFG better in our eyes.

At the same time, CFG makes it possible to actually store the config data into XML.  We just skip the convert to/from XML step in this case and write it directly to someplace on the filesystem. 

CFGs organizational structure is merely what the GUIs display it as.  We thought grouping configurable things (apps, daemons, libraries like GTK, etc.) into more logical groups was best, so thats what we did.  

You can easily modify this by editing the data/config4gnu.xml file to make it whatever you like.  This file basically maps each thing in the heirarchy to the actual config files in /etc or whereever.  Currently, CFG uses the heirarchy defined in that file to locate configuration, but we want to make it possible to say "I want the config for the apache webserver instance #1" or similary, so users can rename & regroup things.

> > 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. 

Yes, CFG does this.  Is it true that GST needs a new front & back end?

Justin


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

Re: [Config4gnu-developer] why not GPL?

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

On Wed, 12 Nov 2003 10:53:54 +0100 (CET)
p.c...@ar... wrote:

> And the main question now is:
> Should proprietary commercial applications for system administration
> be allowed to manage configurations through CFG or should they have to
> figure that out for themselves, with the money they charge.
>
> Maybe just think of Distribution specific Tools like the Yast
> Configuration Tools from newly aquired "Novel @ SuSE". Such special
> Tools are not free, and undermine the free development of a widely
> used configuration system.

Well, here's my only remaining issue with that.  A commercial app isn't going to benefit much by using CFG to read in its configuration, so I don't think thats much of a big deal either way in that regard.  As for front ends, I believe that CFG's frontends should be GPL'd, because they're not libraries, nor are they things that commercial apps should depend on, link against, etc.  

The only thing I think we might want to avoid is a vendor making CFG support their app by creating the proper meta-data for it and maybe a parser.  It would be "bad" if they then made their own non-free GUI that used CFG to manipulate that data.  

HOWEVER, they would have by default added support for their app in ALL of CFG's GUIs.  This is *very significant*, and would give CFG much more use.  If a vendor was able to use CFG to both read their config in their actual app and via some customized GUI, then fine, because by definition if they can do it so can all other apps and GUIs.  *IN FACT*, it would make it possible for people to use CFG to 1) convert/use their config for that non-free app as config for an open source app, and 2) provide a very structured interface into their config for various other uses (automated scripts, installs, etc.).  

I think that failing to encourage vendors to use CFG is a critical error.  What I would suggest is keeping CFG's core under the LGPL, making the UI's (command line, web, graphical, etc.) GPL, and finding some creative way to force vendors to distribute their meta-data files.  
The trick is how to do this without scaring them off.  One idea I've had before is to create a central repository where CFG can go when someone says "I want to configure Samba 3.56.2a".  CFG would go to this central website and automagically install the necessary meta-data, load it, and voila, it is now supported.  This would greatly vendors/authors to put their stuff on the central repository.

There are still some issues if the vendors think that their meta-data is some secret or whatever.  Does anyone have any ideas on how to get around this or find some middle ground so the meta-data is published in some way but vendors are happy?
 
Justin

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

[Config4gnu-developer] Howto checkout Config4GNU

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

There's been a surprising amount of traffic on Config4GNU mailing list
lately... it's reminded me that I'm not the only one that's been thinking
about configuration issues. Anyways, it occurred to me that it might be
helpful to have a HOWTO-style document for getting started with Config4GNU.
What follows is my attempt at this. Most of this I wrote from memory so be
prepared for inaccuracies.

~Jason

--

Checking the code out of CVS

  * Follow the instructions on Sourceforge
  * Basically,
	cvs -z3 co -P config4gnu

The directory structure

  * data/ - contains XML-based class definition files, etc.
  * src/parsers/ - XML-based parsers (read/write configuration files)
  * src/libconfig4gnu/ - C++ library, reads XML definition files, handles
in-memory XML tree of configuration
  * src/wrappers/ - contains Perl and PHP wrappers for the libconfig4gnu
library... parsers use the Perl wrappers
  * src/clients/gtkmm/ - C++ front-end, uses Gtk-- toolkit
  * util/ - other stuff... ask Justin for details. I know one think in here
is XSLT files that convert config definition files provided by Apache
project to Config4GNU's format
  * test/ - build-tests, regression-tests... makes sure parsers don't
mangle the configuration file when reading/writing

Something I recently added...
  * src/providers/
	- these are Perl-based config file readers/writers that DO NOT link
to the libconfig4GNU libraries. The idea is to separate the Config4GNU
parsers from the XML/Xerces dependency. If you can't get the XML-based stuff
to work, you may want to check this stuff out. (See further below.)

Building

  * There is info in README or INSTALL, I can't remember which. Basically
you have to get the Xerces-C++ library installed and know where it is in
case the configure script cannot find it.
  * You'll also need Gtkmm if you want to use the client (recommended).
  * ./configure && make && make install

Run

  * You'll want a Samba configuration file at /etc/samba/smb.conf for the
following to be useful...
  * gtkmm-cfg
	In the left pane, there is a node tree. This node tree is loaded
based on the config4gnu.xml file installed under ${prefix}/etc. As you
expand certain nodes by double-clicking them, a parser is run behind the
scenes and the tree is filled with nodes generated from one or more
configuration files. If you double-click a node the right pane shows "forms"
that are associated with that node type.
	One of the forms that should always be present is the "Properties"
form. On this form, you can double-click a property to view it's
description, as well as any user-added comments. You can also add and remove
properties (try right-clicking).
	Finally, if you make changes and want to save, right-click a node in
the left-pane and choose Save. This invokes the parser again to take the XML
and write it to the configuration file.

The stuff in src/providers/

These are a set of parsers that I've been experimenting with that do not
use the libconfig4gnu library. They do not need anything other than Perl to
run. Unfortunately, there is no corresponding client program. The best you
can do is try running the test-samba.pl program in this directory. The
test-samba.pl program loads the Samba provider, reads in the configuration
file, and then displays the generated configuration tree.

Also in this directory are Perl modules that provide a CORBA-interface to
the configuration data. There is a README file in there that describes what
you need to get the CORBA interface to work. Also, I have a prototype client
written that uses the CORBA interface to access the configuration data, but
I haven't uploaded it to CVS yet.

Re: [Config4gnu-developer] why not GPL?

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

Hello everyone,

> >      So I vote for GPL and allowing "CFG reading"
> 
> This sounds overly complex and provides no benefit.

I don't think it is more complex that stating:

"In addition to the rights set forth in the GPL also "GPL-Incompatible  Free Software" as defined by the gnu.org is allowed to to read and write their configurations though CFG"

The benefit is if projects use CFG they have an interest in maintained meta-config definitions


 
> Let's be clear what we're talking about. There are two types of software
> that 
> will want to link to CFG:
> 
> - One is a piece of software like Samba, that will want to use CFG to manage
> its own configuration file. 
> 
> - The second type, is the Graphical front ends, likely to be parts of the
> KDE or Gnome Control Centre.
> 
> Now if the first type of "user" cannot link to CFG without being GPL, then
> you 
> might as well close down the project now, because it won't go anywhere.
> Forcing these people to license their products as GPL will NOT make them
> open 

Of course not, nobody is forcing anybody here, that is the way it should allways be. The difference is Free (GPL) Software won't die because nobody can "take'em out". BTW all examples above are very welcome free GPL software. Aren't it the people who have the need to configure something. In general, apps just read in the file. People however are free to configure whatever they want with CFG.

Only frontends and other tools might have the need to extensivly use CFG libs.

> their sources, they just wont use CFG. This means they will pollute the /etc
> file tree with their configuration files randomly strewn about, and we will
> have achieved nothing.


CFG is exaclty made and will help to handle that type of cluttered /etc, it already is that way. I've gone over the article again, and IIRC the the example of /services /network etc. you gave was was not to regulate apps to use those directories under /etc but default places where their configuration appear in CFG's XML representation for all frontends.

> Another thing is, it won't be adopted by the major 
> distributions like Redhat and SuSE, and without them, the project might as 
> well be dead.

Damien, i really don't want to sound strange or offend you in any way. I just find it sounds a little like having or spreading fear, uncertainty and doubt against GPL.

It might even be tempting to think that way in some circumstances, I can remember when GPL was new to me I was't so clear about it myself. Or if someone wants to incorporate public work.

Trying to make a ton of money with lots of copies of propriety software that costs you just as much as one copy is like playing the lottery, but is absolutely legitimate. It's the production or service that counts, offering that is also legitimate. Now, is playing lottery with work others invested and put out "for free" legitimate? Depends on the license.


> The reason the Linux kernel project is so successful is because of Linus 
> Torvalds. He is not a politician, but an engineer. He made the decision to 
> allow non-GPL drivers to link against the kernel

Actually, a very good example.
And I came to realize my mistake here. Nobody wants a proprietary Software to "link in" the linux kernel and sell, say  "W-OS 2004" or something. Linux stays firmly under the GPL. Allowing proprietary code to optionally be included under the users risk and "tainting" the kernel however is acceptable.

The Kernel is so great because of Linus and the many contributors. And because it is protected by the GPL, plus allowing things that help the cause. Linux is GPL and even bound to Version 2 at the moment IIRC (not allowing any relaxations per default).

Now to my mistake. I was saying we need an extra statement besides the GPL. I think that might be unnecessary but still a helpful comment.

Apps don't have a problem with linux being GPL, nor should they with CFG being GPL. Only Proprietary System Management Software if it wants to link in parts of CFG and distribute it might not like it.
Isn't the difference between GPL and LesserGPL that the latter allows propropiety Software to "link in" and distribute LGPL Software. Aggregated working is no problem.

At all times is proprietary software allowed to just use gpl software at least by calling the CFG console frontend anyway.

So pure GPL is all that is needed. Other projects as Gnome System Tools came to the same conclusion.

Giving explicit notice that other Free Software is allowed to use CFG-libs and maybe even allowing proprietary Software to read through CFG might however be a wise strategic decision.

-Peter

[Config4gnu-developer] Re: why not GPL? (A vote for LGPL)

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

Zitat von Damien Uern <car...@op...>:
> 
> If you want to further your cause, sometimes you have to concede some things
> in order to coexist with others who don't share your view. Let's not let 
> political motivations ruin a potentially good project.
> 


I do fully agree with this,

and btw.

"He who writes the code gets to choose his license, and nobody
else gets to complain" -- Linus Torvalds


And remember another thing: It's very easy to take some random XML-Lib to take
care of your applications configuration data, so config4gnu should be as
attractive as possible for a large number of developers in order to be widly
deployed.

-Richard

Re: [Config4gnu-developer] why not GPL?

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

On Wed, 12 Nov 2003 8:23 pm, p.c...@ar... wrote:
> Hello,
>
> on  11/12/2003   Justin Yackoski wrote:
> > I'd be for a vote to see what everyone thinks (so far we've only heard
> > from maybe 5-6 people, don't know how many others are lurking in the
> > shadows), but I agree with Damien that LGPL is more friendly and it seems
> > silly to worry very much about arguably minor things when they currently
> > affect the few dozen people that use CFG.
>
> Especialy because we are still a few, but hopefully not for long anymore, I
> think it is good to be clear about the licence. I would say it's fair for
> future users.
>
> And the main question now is:
> Should proprietary commercial applications for system administration be
> allowed to manage configurations through CFG or should they have to figure
> that out for themselves, with the money they charge.
>
> Maybe just think of Distribution specific Tools like the Yast Configuration
> Tools from newly aquired "Novel @ SuSE". Such special Tools are not free,
> and undermine the free development of a widely used configuration system.
>
> > Undoubtedly, the real factor when people pick software is how
> > useful it is.
>
> And in order to promote usefull free configuration frontends we should make
> sure to leave an advantage to them.
>
> LGPL:
> Programms not allowing free use and development can make free use of CFG.
>
> GPL:
> Only Free Programms can make free use of CFG.
>
> An extra statement allowing non-GPL Free Software to do "CFG reading" to
> further promote CFG support is a good idea I think. Maybe even allowing
> proprietary apps to read would make sense.
>
>
>      So I vote for GPL and allowing "CFG reading"

This sounds overly complex and provides no benefit.

Let's be clear what we're talking about. There are two types of software that 
will want to link to CFG:

- One is a piece of software like Samba, that will want to use CFG to manage 
its own configuration file. 

- The second type, is the Graphical front ends, likely to be parts of the KDE 
or Gnome Control Centre.

Now if the first type of "user" cannot link to CFG without being GPL, then you 
might as well close down the project now, because it won't go anywhere. 
Forcing these people to license their products as GPL will NOT make them open 
their sources, they just wont use CFG. This means they will pollute the /etc 
file tree with their configuration files randomly strewn about, and we will 
have achieved nothing. Another thing is, it won't be adopted by the major 
distributions like Redhat and SuSE, and without them, the project might as 
well be dead.

The second type of "user" is not quite so critical as the frontends would 
likely be a part of KDE/GNOME and so would be GPL anyway. However, won't they 
be linking against the same libraries as the first type if user? Or even if 
they weren't, the libraries would be part of the same package, so licensing 
some as LGPL and others as GPL (or GPL with extra clauses) would be 
confusing. 

The reason the Linux kernel project is so successful is because of Linus 
Torvalds. He is not a politician, but an engineer. He made the decision to 
allow non-GPL drivers to link against the kernel, and it was a very good 
decision. You wouldn't be seeing blisteringly fast 3D support with Nvidia 
cards without that decision, and so the entire animated film industry would 
not have decided to use Linux, which generates lots of positive publicity.

If you want to further your cause, sometimes you have to concede some things 
in order to coexist with others who don't share your view. Let's not let 
political motivations ruin a potentially good project.

Cheers,

Damien

>
> > I truly appreciate everyone's feedback, I am very glad that this many
> > people are taking an interest in CFG.
> >
> > Justin
>
> Me too.
> Thank you all for your interest,
> and help Free Software make the difference.
>
> -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] why not GPL?

[Dumas P. <du...@ce...>]

Hi,

I think that it is very important to clear the licence before the project
really take off, it will be much harder later otherwise (all the contributors
holding a piece of the software would have to agree... unless they have
signed a copyright assignement...).

I vote for the GPL. I think that the all or nothing may be a good strategy 
today and preventing proprietary apps from using free software unless they 
also open their code seems to me the way to go, especially for system 
administration. The YACC example seems a good example to me too: keeping
CFG out of YACC could be an argument (an economic incentive...) for the 
YACC licence evolution.

However I think that voting on that issue is not right. I think that the 
developpers should choose, as this is their own code. Argumenting is good, 
though.

Pat

Re: [Config4gnu-developer] why not GPL?

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

Hello,

on  11/12/2003   Justin Yackoski wrote:
> I'd be for a vote to see what everyone thinks (so far we've only heard from
> maybe 5-6 people, don't know how many others are lurking in the shadows),
> but I agree with Damien that LGPL is more friendly and it seems silly to
> worry very much about arguably minor things when they currently affect the
> few dozen people that use CFG.

Especialy because we are still a few, but hopefully not for long anymore, I think it is good to be clear about the licence. I would say it's fair for future users.

And the main question now is:
Should proprietary commercial applications for system administration be allowed to manage configurations through CFG or should they have to figure that out for themselves, with the money they charge.

Maybe just think of Distribution specific Tools like the Yast Configuration Tools from newly aquired "Novel @ SuSE". Such special Tools are not free, and undermine the free development of a widely used configuration system.

> Undoubtedly, the real factor when people pick software is how
> useful it is.  
And in order to promote usefull free configuration frontends we should make sure to leave an advantage to them.

LGPL:
Programms not allowing free use and development can make free use of CFG.

GPL:
Only Free Programms can make free use of CFG.

An extra statement allowing non-GPL Free Software to do "CFG reading" to further promote CFG support is a good idea I think. Maybe even allowing proprietary apps to read would make sense.


     So I vote for GPL and allowing "CFG reading"


> I truly appreciate everyone's feedback, I am very glad that this many people
> are taking an interest in CFG.
> 
> Justin
 
Me too.
Thank you all for your interest,
and help Free Software make the difference.

-Peter

 

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

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

On 10 Nov 2003 09:47:00 +0100
Richard Spindler <csa...@ui...> wrote:

> On Sun, 2003-11-09 at 05:56, Justin Yackoski wrote:
>=20
> > 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.
>=20
> That would be really cool.

OK, I've been sick the past 2 days so I'm pretty behind on things.  It will=
 probably take me another few days to get around to it, but I will do it as=
 soon as I can.

> > Which leads me to the question... what programming language does
> > your project use?
>=20
> 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-Stuff.

Ok, our stuff is currently in a combination of C++ and Perl, although we ha=
ve been using SWIG to generate wrappers for our library.  SWIG claims to su=
pport Python so it should be possible to use Python, although I've never tr=
ied it. =20

I just got SWIG to compile the wrapper successfully, you might try copying =
the src/wrappers/perl5 directory to src/wrappers/python and replacing every=
 occurance of perl5 with python and pm with py.  That should get it to buil=
d.  I don't know python very well, but I'll try to check in a working pytho=
n wrapper Makefile in the next few days for you if you have trouble copying=
 the perl one.

You can also look at the src/clients/php/ directory for an example of how P=
HP interacts with its wrapper to work with the config data.

Let me know if you have any trouble.

Justin

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

Re: [Config4gnu-developer] why not GPL?

[Jan W. <Jan...@TU...>]

Hello,
yeah i like the LGPL. It's just more appropriate for infrastruture issues. And 
now lets concentrate on technical aspects ;)
Bye
  Jan 

Re: [Config4gnu-developer] why not GPL?

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

On Tue, 11 Nov 2003 12:17:04 +0100 (CET)
p.c...@ar... wrote:
<snip>
> Let's state clearly that BSD and other not gpl-compatible but still
> free software (as defined at gnu.org) can use CFG to read their
> configuration. I don't think being beeing clear copyleft and promoting
> free software would limit usefulness and the uptake of Free Software,
> just look to what happend during the last 30 years.
> 
> I think CFG will make a huge difference and be an advantage. And as
> RMS writes we need advantages for free software developers to make it
> to 100% again.

Again, I don't pretend to fully understand all the licensing issues involved.  I also think its hard to judge how this will affect CFG's level of use.  Undoubtedly, the real factor when people pick software is how useful it is.  

I'd be for a vote to see what everyone thinks (so far we've only heard from maybe 5-6 people, don't know how many others are lurking in the shadows), but I agree with Damien that LGPL is more friendly and it seems silly to worry very much about arguably minor things when they currently affect the few dozen people that use CFG.

I truly appreciate everyone's feedback, I am very glad that this many people are taking an interest in CFG.

Justin

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

Re: [Config4gnu-developer] Re: cfengine and config4gnu

[Christian P. <pe...@co...>]

This is a good paper.  I met one of the guys who wrote this paper (I forget which one) at the Cfengine workshop at Lisa '01.  I based some of Systems Navigator on what they wrote about.  SysNav is a basically an infrastructure tool for a enterprise in the setting of a portal.  

http://www.commnav.com/products/systems_navigator.php

--
Christian Pearce
http://www.commnav.com



p.c...@ar... said:
> 
> 
> A kind person sent me the URL to an cfengine article that gives a good overview:
> http://astro.uchicago.edu/~davidr/cfengine-tools/lisa-paper_html
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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] why not GPL?

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

Hello,
you are right this is a matter of believes I guess. 

> Why did RMS create the LGPL in the first place? It was a strategic decision.
[...]
> 
> The Free Software world is creating a _platform_ for software to be written
> for and deployed on. We have to realise that proprietary software is not 
> going away, and we should be enticing these companies to port their products
> to the GNU/Linux platform.

Of course it won't go go away, but on the other hand this isn't the goal of free software anyway. We just want to have somthing good we can work with, and be able to help each other now and in the future.

BTW: Anyone noticed the word _platform_ being used all over the corporate place and what they might mean by it?

Have you read http://www.gnu.org/philosophy/why-not-lgpl ?

It is not about beeing against or anti-something. However it seems to me that unfortunately many tend to have that kind of attitude at least in some early stages of the understanding of Free Software. Maybe some proprietary monopoly made them have such a dark outlook on things, I don't know.

That is not right, let's not be negative. 

> 
> There are some instances where Free Software doesn't have an answer, and so
> to 
> get the job done, people use proprietary software (e.g. Adobe Photoshop). 
> Should those people then be forced to use a 100% proprietary system
> (Windows + photoshop) ? Or would it be better if we could get most people
> using a 95% Free Software System?

Of course, and there is great free software to make this possible. I know some people have their photoshop in wine with linux.

But the 95% is the interesting figure for us. We want to improve it, and we came from a full 100%. Yes, but the freedom of the code was not guaranteed so it got taken away somehow along the line. 

> The "All or Nothing" approach can be very damaging, and would limit the 
> usefulness and uptake of Free Software systems. Not to mention the fact that
> most BSD people dislike the GPL, and we would be scaring them off.

Let's state clearly that BSD and other not gpl-compatible but still free software (as defined at gnu.org) can use CFG to read their configuration. I don't think being beeing clear copyleft and promoting free software would limit usefulness and the uptake of Free Software, just look to what happend during the last 30 years.

I think CFG will make a huge difference and be an advantage. And as RMS writes we need advantages for free software developers to make it to 100% again.

Regards
-Peter

[Config4gnu-developer] Problem with compiling 0.1.8

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

Hi,
I tried to compile Version 0.1.8 of config4gnu, but it stopped with the
following error message:

--

make[3]: Wechsel in das Verzeichnis Verzeichnis
=BB/home/oracle/Downloads/config4gnu-0.1.8/src/wrappers/perl5=AB
/bin/sh ../../../libtool --mode=3Dcompile c++ -DPACKAGE=3D\"config4gnu\"
-DVERSION=3D\"0.1.8\" -DHAVE_DLFCN_H=3D1 -DENABLE_GTKMM=3D1  -I. -I.=20
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2 =20
-I/home/oracle/Downloads/xerces_c-2.3.0/include       =20
-I/usr/lib/perl5/5.8.0/ppc-linux-thread-multi/CORE       =20
-I../../../src/libconfig4gnu    -g -O2 -c config4gnu_wrap.cxx
rm -f .libs/config4gnu_wrap.lo
c++ -DPACKAGE=3D\"config4gnu\" -DVERSION=3D\"0.1.8\" -DHAVE_DLFCN_H=3D1
-DENABLE_GTKMM=3D1 -I. -I. -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/lib/sigc++-1.2/include
-I/usr/include/sigc++-1.2
-I/home/oracle/Downloads/xerces_c-2.3.0/include
-I/usr/lib/perl5/5.8.0/ppc-linux-thread-multi/CORE
-I../../../src/libconfig4gnu -g -O2 -c config4gnu_wrap.cxx   -fPIC -DPIC
-o .libs/config4gnu_wrap.lo
In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:32,
                 from ../../../src/libconfig4gnu/CfgObject.h:6,
                 from config4gnu_wrap.cxx:567:
/usr/include/sigc++-1.2/sigc++/object.h:51:14: macro "ref" requires 2
arguments, but only 1 given
In file included from /usr/include/sigc++-1.2/sigc++/sigc++.h:32,
                 from ../../../src/libconfig4gnu/CfgObject.h:6,
                 from config4gnu_wrap.cxx:567:
/usr/include/sigc++-1.2/sigc++/object.h:51: variable or field `ref'
declared=20
   void
/usr/include/sigc++-1.2/sigc++/object.h:176:27: macro "ref" requires 2
arguments, but only 1 given
In file included from config4gnu_wrap.cxx:571:
../../../src/libconfig4gnu/CfgMisc.h:7:44: macro "convert" requires 3
arguments, but only 1 given
../../../src/libconfig4gnu/CfgMisc.h:8:34: macro "convert" requires 3
arguments, but only 1 given
In file included from config4gnu_wrap.cxx:571:
../../../src/libconfig4gnu/CfgMisc.h:8: conflicting types for
`XMLCh*convert'
../../../src/libconfig4gnu/CfgMisc.h:7: previous declaration as
`std::string=20
   convert'
make[3]: *** [config4gnu_wrap.lo] Fehler 1
make[3]: Verlassen des Verzeichnisses Verzeichnis
=BB/home/oracle/Downloads/config4gnu-0.1.8/src/wrappers/perl5=AB
make[2]: *** [all-recursive] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis
=BB/home/oracle/Downloads/config4gnu-0.1.8/src/wrappers=AB
make[1]: *** [all-recursive] Fehler 1
make[1]: Verlassen des Verzeichnisses Verzeichnis
=BB/home/oracle/Downloads/config4gnu-0.1.8/src=AB
make: *** [all-recursive] Fehler 1

--

I'm using YellowDog Linux 3.0, libsigc++-1.2.5, gtkmm-2.2.8,
libglademm-2.0.1, gcc-3.2.2, xerces-c-2.3.0

Is there something I can do about this?
Should I give the CVS-Version a try?

regards
Richard

Re: [Config4gnu-developer] why not GPL?

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

On Tue, 11 Nov 2003 9:09 am, p.c...@ar... wrote:
> > > I do not see however why commercial apps should benefit in a freerider
> >
> > manner from the works of the free software world.
> >
> > Sorry if I look a bit pedantic, but I disagree on the "freerider" use,
> > there.
>
> [...]
>
> > Passing from LGPL to GPL force proprietary apps to allow free use for
> > everybody, including free riders.
>
> Hmm. Yes I understand, you are right. The the sentence was not correct.
> Maybe better:
> Why should non-free apps benefit from the works of the free software world?
>

Why did RMS create the LGPL in the first place? It was a strategic decision. 
RMS is the most hardlined, non-compromising, person in the Free Software 
world, and even he saw the reason to allow proprietary software developers to 
run software on top of a GNU system.

The Free Software world is creating a _platform_ for software to be written 
for and deployed on. We have to realise that proprietary software is not 
going away, and we should be enticing these companies to port their products 
to the GNU/Linux platform.

There are some instances where Free Software doesn't have an answer, and so to 
get the job done, people use proprietary software (e.g. Adobe Photoshop). 
Should those people then be forced to use a 100% proprietary system (Windows 
+ photoshop) ? Or would it be better if we could get most people using a 95% 
Free Software System?

The "All or Nothing" approach can be very damaging, and would limit the 
usefulness and uptake of Free Software systems. Not to mention the fact that 
most BSD people dislike the GPL, and we would be scaring them off.

> > Pat
>
> Thanks,
> Peter
>
>

Cheers,

Damien

>
>
>
>
>
>
>
> -------------------------------------------------------
> 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] why not GPL?

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

> > I do not see however why commercial apps should benefit in a freerider
> manner from the works of the free software world.
> 
> Sorry if I look a bit pedantic, but I disagree on the "freerider" use,
> there.
[...]
> Passing from LGPL to GPL force proprietary apps to allow free use for 
> everybody, including free riders.

Hmm. Yes I understand, you are right. The the sentence was not correct.
Maybe better:
Why should non-free apps benefit from the works of the free software world?

> 
> Pat

Thanks,
Peter

Re: [Config4gnu-developer] Re: cfengine and config4gnu

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

A kind person sent me the URL to an cfengine article that gives a good overview:
http://astro.uchicago.edu/~davidr/cfengine-tools/lisa-paper_html

Re: [Config4gnu-developer] why not GPL?

[Dumas P. <du...@ce...>]

Hi,

> I do not see however why commercial apps should benefit in a freerider manner from the works of the free software world.

Sorry if I look a bit pedantic, but I disagree on the "freerider" use, there.
As long as a person can use a software for free, that is without paying back 
or contributing with code and do it, this person free rides. The GPL 
explicitely permits or better encourage this. What the GPL forbids is 
forbidding others to free ride or contribute. The whole point is that free 
riding is good because the software is a public good (even if contributing 
is even better). If people weren't allowed to free ride then money 
availability would be a barrier for software use.

Passing from LGPL to GPL force proprietary apps to allow free use for 
everybody, including free riders.

Pat

Re: [Config4gnu-developer] why not GPL?

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

On Mon, 2003-11-10 at 16:16, p.c...@ar... wrote:
> Hello Damien,
> 
> > The libraries that apps link to should be LGPL, and XML files should
> > be whatever license the author wants to use.
> 
> Apps and XML files can of course be under any license. As you said this
> is a infrastructure project giving other free software developers a huge
> advantage. I do not see however why commercial apps should benefit in a
> freerider manner from the works of the free software world.

Let's wait and see how far c4g will be deployed and then worry about
such issues. IMHO

> The thread and the mentioned why-not-lgpl document talked about this.
> 
> By using GPL and explicitly _allowing_ Software under other free licenses
> to use CFG to read configurations the use would not be limited to GPL-
> compatible software anymore.

This might become very complicated, because then the term "other free
licenses" has to be defined too.

BTW. Adding certain conditions to existing Licenses like the GPL is
always a bad Idea IMHO, because it confuses users.


That's all of course, only my humble opinions :)

-Richard


-- 
Richard Spindler <csa...@ui...>

Re: [Config4gnu-developer] why not GPL?

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

Hello Damien,

> The libraries that apps link to should be LGPL, and XML files should
> be whatever license the author wants to use.

Apps and XML files can of course be under any license. As you said this is a infrastructure project giving other free software developers a huge advantage. I do not see however why commercial apps should benefit in a freerider manner from the works of the free software world.

The thread and the mentioned why-not-lgpl document talked about this.

By using GPL and explicitly _allowing_ Software under other free licenses to use CFG to read configurations the use would not be limited to GPL-compatible software anymore.

cheers,
-Peter

Re: [Config4gnu-developer] why not GPL?

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

I believe an infrastructure project should not force licensing choices upon 
people. The libraries that apps link to should be LGPL, and XML files should 
be whatever license the author wants to use. If I write a program in perl, I 
don't have to release that program under the same license as the perl 
interpreter. Similar thing here.

I may have gotten the wrong end of the stick as I haven't followed the whole 
thread. 

Cheers,

Damien

On Tue, 11 Nov 2003 12:26 am, p.c...@ar... wrote:
> Hi,
>
> > 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?
>
> I have found somthing on that matter. If I understand correct, modified BSD
> licenses wont have a problem.
>
> The apache webserver might need a statement.
>
> I guess a statment allowing all "Free Software Licenses" to read should do
> it. (of course in somehow more legal terms)
>
> Diffenrent lincenses are discussed here:
> http://www.gnu.org/philosophy/license-list.html
>
> > Justin
>
> -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] why not GPL?

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

Hi,

> 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?

I have found somthing on that matter. If I understand correct, modified BSD licenses wont have a problem.

The apache webserver might need a statement.

I guess a statment allowing all "Free Software Licenses" to read should do it. (of course in somehow more legal terms)

Diffenrent lincenses are discussed here:
http://www.gnu.org/philosophy/license-list.html

> 
> Justin

-Peter

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

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

On Mon, 10 Nov 2003 11:30 pm, p.c...@ar... wrote:

[SNIP!]
> Here I have copied some notes from Damien Uern who was also looking into
> GST and CFG. Trying to benefit both he writes:
>
> ----------
>
> > [GST] 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!).
>
> I do not understand, how would CFG try to change the programs?

Well CFG wants to alter the structure of the /etc file tree, no? e.g

/etc/applications
/etc/services
....

At the very least, the paths to these new config file locations would need to 
be modified in the applications. I think it would be better to not hardcode 
such paths into the program, but rather provide a library that knows the 
locations of these files. That way, the config file can be moved around, and 
the program using that config file wont break. 

Imagine that; flexibility. That's what Unix is all about isn't it? So why do 
95% of programs have paths to files/data set at compile time?

>
> > 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.
>
> -----------
>
>
> Have a good day!
> -Peter
>

Cheers,

Damien

> > > 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.
>
> -------------------------------------------------------
> 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