Menu
▾
▴
config4gnu-developer — Config4GNU developers list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(44) |
Nov
(18) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(12) |
Feb
(5) |
Mar
(8) |
Apr
(51) |
May
(1) |
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(8) |
Oct
(1) |
Nov
(53) |
Dec
(17) |
| 2004 |
Jan
(20) |
Feb
(18) |
Mar
(11) |
Apr
(2) |
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(6) |
| 2007 |
Jan
(1) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Justin Y. <ju...@sk...> - 2003-12-14 21:30:05
|
sounds good to me. Peter, are you familiar w/ the process of adding a list to their archive? If so, feel free to, otherwise I'll poke around with it tomorrow. On Fri, 12 Dec 2003 17:04:05 +0100 (CET) p.c...@ar... wrote: > > As the sf.net Archive does not seem to work all the time and messages > get archived with a huge delay I would suggest to add this list to > gmane.org which has nice archiving and news features. > > Any objections? > > -Peter > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for > IBM's Free Linux Tutorials. Learn everything from the bash shell to > sys admin. Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > Config4gnu-developer mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/config4gnu-developer > > -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: <p.c...@ar...> - 2003-12-12 16:04:08
|
As the sf.net Archive does not seem to work all the time and messages get archived with a huge delay I would suggest to add this list to gmane.org which has nice archiving and news features. Any objections? -Peter |
|
From: <p.c...@ar...> - 2003-12-12 15:13:21
|
Hi, look at the debian wiki they too think about cfg and would look forward to it. Please let us not seem like rejecting any incoming interest or being stalled. http://wiki.debian.net/index.cgi?DebConf IMHO priority should really be to push CFG now. Testability and usability contributeability. Document how to easily write a basic meta-config-definition and get CFG support. To make it easier for all to do somthing for the project we could use a wiki somewhere. For example the FAQs I submitted last week could be gathered there in a contributing way much easier and with less hassle for you. Any ideas about a proper location? -Peter |
|
From: C. G. <c.g...@tu...> - 2003-12-10 12:40:43
|
Am Freitag, 5. Dezember 2003 23:56 schrieb C. Gatzemeier: > how are your thoughts about naming conventions? > I have not found docs about it. > > I've seen: > /data/parsers > /data/forms > /data/classes > > should these go under /usr/share during install and be the place where > other packages should drop their definitions too? > > How have you pictured multiple version handling? Do you have knowledge > about kconf_update? > Would the following be a reasonable approach for the meta-data?: > Please add your thoughts. > > /cfg-definitions/config4gnu.xml > /cfg-definitions/classes/builtin.xml etc. Regarding the individual projects source directories (cvs) I may add that a subdirectory named <projectname>-<version>.cfg (with the .cfg) seems to fit better, and during installation i.e. could be copied to: /cfg-definitions/apache-1.x.cfg/ /cfg-definitions/apache-1.x.cfg/parser.xml /cfg-definitions/apache-1.x.cfg/config.xml /cfg-definitions/apache-1.x.cfg/xform (or better forms.xml and wizards.xml?) /cfg-definitions/apache-1.x.cfg/virtualdomain.xform (or virtualdomain-form.xml and virtualdomain-wizard.xml?) (wherever /cfg-definitions live) Please comment on this, especially about different versions, it might not make sense at all to have different dirs per version if versions are better handled within the meta-config-definition itself. All the best, Christian |
|
From: Richard S. <csa...@ui...> - 2003-12-10 12:17:34
|
C. Gatzemeier schrieb: > Am Mittwoch, 10. Dezember 2003 12:35 schrieb Richard Spindler: > >>Hm, right now I'm trying to get some people together, to build the most >>powerful XFree-Configuration Tool on top of CFG. > > > Cool, do you already have some pointer/link to your efforts? Yes, see: http://oracle2025.ath.cx/oracle/xfree-config-tool/ But there's no Code yet. -Richard |
|
From: C. G. <c.g...@tu...> - 2003-12-10 11:53:05
|
Am Mittwoch, 10. Dezember 2003 12:35 schrieb Richard Spindler: > Hm, right now I'm trying to get some people together, to build the most > powerful XFree-Configuration Tool on top of CFG. Cool, do you already have some pointer/link to your efforts? Christian |
|
From: Richard S. <csa...@ui...> - 2003-12-10 11:35:46
|
C. Gatzemeier schrieb: > I think it is most important for CFG to get some power users or better yet > communities to easily test and taste CFG (and see the beauty of it). Then, > when they are "hooked" they will have some itching and chances are higher > that they contribute ;-) > Hm, right now I'm trying to get some people together, to build the most powerful XFree-Configuration Tool on top of CFG. We're in a very early stage of planning, and at the Moment all the discussion takes place in german. (We plan to switch our Project Language to english as soon as we're a little more familiar with the CFG enviornment.) -Richard |
|
From: C. G. <c.g...@tu...> - 2003-12-05 22:53:59
|
Hello, another question I have: Would it be hard for you, or even viable, to provide meta-config definitions for the current CFG meta-config-file format? Maybe CFG itself could be used as a nice XML editor for meta-config definitions? What do you think? I would like to try CFG out with some application I have installed. I think it is most important for CFG to get some power users or better yet communities to easily test and taste CFG (and see the beauty of it). Then, when they are "hooked" they will have some itching and chances are higher that they contribute ;-) All the best, Christian |
|
From: C. G. <c.g...@tu...> - 2003-12-05 22:47:22
|
Dear cfg-list, how are your thoughts about naming conventions? I have not found docs about it. I've seen: /data/parsers /data/forms /data/classes should these go under /usr/share during install and be the place where other packages should drop their definitions too? How have you pictured multiple version handling? Do you have knowledge about kconf_update? Would the following be a reasonable approach for the meta-data?: Please add your thoughts. /cfg-definitions/config4gnu.xml /cfg-definitions/classes/builtin.xml etc. /cfg-definitions/apache-1.x/ /cfg-definitions/apache-1.x/parser.xml /cfg-definitions/apache-1.x/config.xml /cfg-definitions/apache-1.x/xform (or better forms.xml and wizards.xml?) /cfg-definitions/apache-1.x/virtualdomain.xform (or virtualdomain-form.xml and virtualdomain-wizard.xml?) All the best, Christian |
|
From: <da...@id...> - 2003-12-01 14:33:20
|
Hello guys, sorry to interrupt, but I'm going to code some xml frontend to
libconf. Libconf is basically in the same area than CFG and GST :)
I think those 3 projects have a lot of things similar, maybe that'd be good to
agree on file formats that could be similar, and maybe some APIs?
Sorry if I come late in this discussion.
Justin Yackoski <ju...@sk...> said:
> On Thu, 27 Nov 2003 11:10:16 +0100
> Lars Hallberg <la...@mi...> wrote:
>
>> Justin Yackoski wrote:
>>
>> >I think that what you guys have done is great, and hate to see
>> >duplicate effort. So lately I've been thinking about the differences
>> >between CFG and GST to try to figure out what we have in common and
>> >how we might be able to join forces.
[...]
> In our CVS, see /config4gnu/test/perl/sample_perl.pl for an example of getting & reading a config file. (you'll have to do a make test in /config4gnu/test/perl to create it) Just set the values you'd like, and then call save() on the object you get from the resolve_path("/Whatever/Something") call, in the example script this would be $samba. (Jason please correct me if I'm wrong).
>
> Justin
--
dams
|
|
From: Justin Y. <ju...@sk...> - 2003-12-01 03:37:15
|
On Thu, 27 Nov 2003 11:10:16 +0100
Lars Hallberg <la...@mi...> wrote:
> Justin Yackoski wrote:
>
> >I think that what you guys have done is great, and hate to see
> >duplicate effort. So lately I've been thinking about the differences
> >between CFG and GST to try to figure out what we have in common and
> >how we might be able to join forces.
> >
> >Unfortunately, it seems that the only thing we could potentially
> >share is that CFG's parsers could probably be used by GST, but the
> >XML from the GST frontends would first have to go through an
> >intermediary that was a lot smarter than CFG's parsers.
> >
> >
>
> If the CFG midellayer have some kind of service id and version control
> on the XML excanged with the frontend, it must be possable to add
> 'alternative' fatter frontend moduls. And if the versions don't agree,
> simply fall back to the generic frontend.
>
> Must be a huge win without giving up any freedom in ui design. And
> reduce duplicaton of effort significantly!
There should certainly be a version/revision control system applied to the XML as it goes thru the middle layer. We don't do that right now, but it is one of the features we feel are very important.
As for the service ID, such as saying "give me the config for the system's primary network device (eth0, ppp0, etc.)" or "give me the config for samba" without knowing the exact path (i.e., /services/samba), I think supporting fatter front ends or other tools is a very good reason to include this. There are a couple of ways we could implement this, but probably the simplest is just to create a list of mappings from service ID to their path in the master XML document that CFG edits.
If CFG was able to do this, would other config tools consider using it for a fair portion of their behind the scenes stuff? Or are there still other issues to be resolved?
> BTW, do CFG have any stable 'virtual' interfaces for seting upp
> standard stuf - preferably with an option to do it only temporarly
> (ie, reset on next boot). Would be great for stuff like DHCP scripts
> and curently, netenv that I use and need to set different nameservers,
> domain, hosts depending on the conection point - but without
> disturbing the 'default' config. Just prepering some set of XML files
> to feed the cfg depending on environment, leving all the details of
> config file format and changes in them to the cfg would be great :-)
We have a working demo of a "script interface" to CFG. You can basically use a DOM interface to get at something's configuration, change some values, and save your changes. CFG doesn't do revision control currently, but you could easily create one script to setup each of your different environments, and then one more that sets everything to its defaults.
In our CVS, see /config4gnu/test/perl/sample_perl.pl for an example of getting & reading a config file. (you'll have to do a make test in /config4gnu/test/perl to create it) Just set the values you'd like, and then call save() on the object you get from the resolve_path("/Whatever/Something") call, in the example script this would be $samba. (Jason please correct me if I'm wrong).
Justin
--
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com
|
|
From: <p.c...@ar...> - 2003-11-29 14:20:39
|
Jason Long wrote: > I noticed current versions of OpenLDAP server provide a "Perl backend." I'm > going to check it out, and I hope I can get it to work without much > trouble. > I think it would be really cool to make configuration data available via > LDAP. Yes, and how is the idea of an "LDAP parser" for CFG? Might be cool for systems that already use LDAP for some configs. CFG also beeing a nice LDAP config framework? -Peter |
|
From: Lars H. <la...@mi...> - 2003-11-27 10:10:18
|
Justin Yackoski wrote: >I think that what you guys have done is great, and hate to see duplicate effort. So lately I've been thinking about the differences between CFG and GST to try to figure out what we have in common and how we might be able to join forces. > >Unfortunately, it seems that the only thing we could potentially share is that CFG's parsers could probably be used by GST, but the XML from the GST frontends would first have to go through an intermediary that was a lot smarter than CFG's parsers. > > If the CFG midellayer have some kind of service id and version control on the XML excanged with the frontend, it must be possable to add 'alternative' fatter frontend moduls. And if the versions don't agree, simply fall back to the generic frontend. Must be a huge win without giving up any freedom in ui design. And reduce duplicaton of effort significantly! BTW, do CFG have any stable 'virtual' interfaces for seting upp standard stuf - preferably with an option to do it only temporarly (ie, reset on next boot). Would be great for stuff like DHCP scripts and curently, netenv that I use and need to set different nameservers, domain, hosts depending on the conection point - but without disturbing the 'default' config. Just prepering some set of XML files to feed the cfg depending on environment, leving all the details of config file format and changes in them to the cfg would be great :-) /LaH |
|
From: Jason L. <jl...@me...> - 2003-11-22 22:41:26
|
I noticed current versions of OpenLDAP server provide a "Perl backend." I'm going to check it out, and I hope I can get it to work without much trouble. I think it would be really cool to make configuration data available via LDAP. Jason |
|
From: Justin Y. <ju...@sk...> - 2003-11-22 18:58:26
|
Sorry for the slow response. Our meta-config actually does not have a DTD for a couple of reasons. While we never actually tried, I don't think our meta-data could be validated against a schema/dtd. All our XML nodes are defined in meta-data as basically sub-classes of other nodes. Because of this, there are 2 problems with using standard schema/dtd validation, I'm assuming you're referring to #1 but I'll include #2 anyway. 1) each node defined in meta-data can have ANY child elements that it wants to. While they are restricted to certain classes of nodes, current XML libraries don't support this type of validation. So, we can't validate them in the traditional way. It would be possible to write our own validator to do a good amount of sanity-checking, but we have not done this yet. 2) the actual config data that comes from one of our more generic parsers (i.e., the apache-*style* parser) could be validated against a DTD. However, in practice we primarily use more specific parsers, and by the time the XML reaches the front-ends, it may have additional nodes added to it as defined in the meta-data, which as mentioned in #1 can't be validated using traditional XML libs. So, you'd have to look at our extending howto at http://config4gnu.sourceforge.net/docs/extending/ particularly the section on adding entities. Also in CVS take a look at config4gnu/data/classes/ to see our current meta-data files. I think our XML is similar in approach to kconfig's, but we've got a few more advanced things in our meta-data and it is more system-wide while theirs seems to be geared mostly toward the GUIs. Justin On Thu, 13 Nov 2003 17:46:29 +0100 (CET) p.c...@ar... wrote: > > Hi, > where is the file format for meta-config definitions defined? > Because this might be interesting: > > ----- Original Nachricht ---- > Waldo Bastian (bastian (at) kde org) > 13.11.2003 17:18 > Re: kconf_update > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu November 13 2003 16:38, you wrote: > > Hello Bastian, > > > > I read the KDE feature plan, and stumbled over this: > > > > Give kconf_update the ability to filter generic, non-KConfig files. > > Waldo Bastian <ba...@kd...> > > > > Maybe you already know, but if not, it might be very intersting! > > There is a simple and generic framework called CFG (or config4gnu > > for long) that might be good help. We can offer an easy way to > > manipulate general system settings and more. > > Yes, I read something like that. Do you have more info about the > format that you use for meta-config information? For KConfig we > started using an XML format for that as described by > http://www.kde.org/standards/kcfg/1.0/kcfg.dtd > > Cheers, > Waldo > - -- > ba...@kd... -=|[ SUSE, The Linux Desktop Experts ]|=- > ba...@su...-----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE/s67UN4pvrENfboIRAsGNAKCDbxim5vNf3vh5aamBPJ8AOcz4XQCgqttp > MS7opnZVfOqOTLSRF9BlZT4= > =ibd4 > -----END PGP SIGNATURE----- > > > > > > > ------------------------------------------------------- > 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 > > -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Justin Y. <ju...@sk...> - 2003-11-22 18:41:39
|
On Wed, 19 Nov 2003 09:57:56 -0500 Carlos Garnacho <gar...@tu...> wrote: > > > > 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? > > if the feature added is just to add support for X to distro Y, then > you only need to change the backend, no changes to the frontend are > needed, but if you are adding a new functionality/configuration tool, > then you might want to write a new frontend > > BTW, the frontends are designed to be as small as possible, the > biggest one has ~7000 code lines, and the smallest <1000, that's > mostly a little ammount of code that IMHO respects as much as possible > the several GUI guidelines I think that what you guys have done is great, and hate to see duplicate effort. So lately I've been thinking about the differences between CFG and GST to try to figure out what we have in common and how we might be able to join forces. Unfortunately, it seems that the only thing we could potentially share is that CFG's parsers could probably be used by GST, but the XML from the GST frontends would first have to go through an intermediary that was a lot smarter than CFG's parsers. I think the major design difference is that CFG has a large middle layer (which uses the XML meta-data) and very dumb bottom and top layers. Instead of a shared middle layer, GST puts all the meta-data about configuration into either the backend or frontend. This makes the two systems rather incompatible because our backends are too simple for your frontends, and your backends wouldn't be usable by us because our frontends are too simple to work without additional meta-data. IMHO, sharing a single backend among frontends as GST does is a step forward from existing config tools, but having a smart middle layer and pretty dumb front and back ends is an even better approach. It makes everything much more modular, and if the middle layer is fully driven by XML files, then changing/adding its support is MUCH simpler, and various other apps can add or update their XML meta-data files during their installs, so the actual config tool doesn't need to be recompiled or updated most of the time. I think that if GST didn't feel a need for smart frontends, you'd probably move toward a middle layer of some sort and make the backends be a little dumber as well. It seems GST's reservation for not having very generic frontends is that some things appear to need hardcoding to make them HIG compliant and easy to use. After working with CFG for a year, I am very confident that this is quite simply not the case. We've had many people criticize CFG for this exact reason, but we haven't yet come across a special case with either the backend's data parsing or the frontend's data display that could not be handled by additional XML meta-data and some minor changes to the middle layer to use that additional meta-data. I'm very curious as to what special cases you've come across that were hard/impossible to handle more generically. I'm also curious as to why GST decided that it was better to treat every type of special case (even those that could be easily handled by a middle layer) with code in the affected backend and frontends, instead of just using a middle layer for everything it could be used for, and then resorting to a much smaller amount of hard-coding. There may very well be good reasons that we just haven't thought of, but right now I can't come up with any, which is making it hard for me to understand your lack of a middle layer. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: <p.c...@ar...> - 2003-11-19 20:24:12
|
On 11/13/2003 10:02 Carlos Garnacho wrote: > the idea that the HST/XST/GST wanted to inspire is that creating > frontends for a single backends should be a "trivial" task, keeping them > only a few thousand lines long, and I think that this is true for any > graphical/text library you want to use A very good idea, and they probably have inspired CFG a great deal. Now CFG offers a way to even trivialize creating support for new things to configure in all frontends simultaniously. The idea can also be true for any application/service you want to use. > > 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? > > The frontends should be written for every GUI/text library, the backend > would be common for all frontends, for example, there is knetworkconf, > which uses the network-conf backend This is ok as long as a frontend reimplementation is only needed in order to get a native app for a particular GUI/text library, or if you want to follow other HID guidelines with your frontend. The middlelayer stays the same for all frontends. Reimplementing and maintaining every configuration feature in each frontend is however very inefficient. > > To support a new application distribution independent in all [CFG] frontends > only its meta-configuration datails needed. (syntax, options, defaults and > logic in the form of an xml file) > > :-? but it is sometime neccesary, for example, the boot-conf backend is > able right now to configure grub and lilo, but there's a (at least > little) need of hardcoding some issues. could you explain me this more > deeply? CFG and its frondends do not have or need a special "boot-conf" or other functions. It can simply configure all files it has a meta-config-description for. In general there is only one "bootloader" package grub or lilo installed, together with it it's meta-config. So CFG middlelayer finds it and a new configuration node is added to the xml-tree. IMHO there are sometimes mismatches between the functionality of > some similar tools that may need hardcoding... :) This is only true from the standpoint that all different but simillar tools should be configured by the same and "easy looking" hardcoded functional oriented GUIs. But how easy it can be to configure a package is defined by the package itself. A package or configration file oriented system like CFG can provide the easiest (even multiple) way to configure a file with the meta-configuration-data. Lilo and grub will differ in their capabilities so will probabliy their configurations, it might still be possible to have the wizards defined in their meta-configrations ask the same questions. > anyways, the GST backends are flexible enough for adding easily more > support for other programs and configuration files If GST, other frondends and even the applications themselfes use CFG as its "backend", thousends of new lines of code would only be neccessary to make the whole system configuration available under new UI-Guidelines or other toolkits. And not each time someone wants to have a new function in his particular Frontend. Not talking of the ongoing need for maintanance of hardcoded frontends due to changes in the packages configuration or handling of different versions. Kind regards, Peter |
|
From: Richard S. <csa...@ui...> - 2003-11-15 18:39:43
|
That' strange, I had to comment the following line in /usr/lib/swig1.3/perl5/std_mqp.i and /usr/lib/swig1.3/php4/std_mqp.i out, to get it compiling. //%include std_common.i and btw. xerces had to be compiled as single-threaded library, but anyway, I don't think this has anything to do with c4g -Richard |
|
From: <p.c...@ar...> - 2003-11-15 16:21:13
|
Hello everybody,
there seems to be quite a delay on the sf listservers, still nice to see so many participating.
On Nov. 13th 2003 Justin Yackoski wrote:
> 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.
Thank you Justin, for comming up with this really practical example. It nicely shows that full *integration into the CFG* system has to be _possible_ and _encouraged_ for commercial vendors, too.
It is _possible_ at all times because the protokol to communicate with the middlelayer is public, isn't it?
It is _not_encouraged_ by putting "the core of CFG" under LGPL.
The LesserGPL allows to distribute a proprietary Produkt containing CFG, meaning "integrate CFG into vendors product" ("MS Configure").
We can _encourage_ the regular use of CFG by having good features and being easy to use. Being free and having no licence fees may also count, but maybe not so much for commercial vendors.
CFG is unique in it's integrating way and has, no doubt, many benefits even for vendors. They can easily access the configuration of the whole system etc. So some might actually really want to integrate this functionallity into their products (to exploit). And if they are allowed to do so, be sure they will find ways so others do not benefit from their parsers or meta-configuration-data.
To promote a wider regular use of CFG also in proprietary products we could publish only the libraries with the functions to easily access the CFG middlelayer under the LGPL. These libraries could then be integrated into all frontends including commercial ones. This is parallel to gcc (GPL) and the C runtime library (LGPL). Note that there are already many other (even free) XML-libs so not much is given away.
But the downside when publishing the access libs under LGPL is that there is no incentive for others to make their Frontends or Tools free or to contribute to free frontends instead. Since it is just as easy to tap the sources and close the license.
The decision is weather to maintain an advantage and therefore an incentive for free development of CFG tools and fontends or to give that up just in order to make regular use of CFG a little easier for vendors. Those vendors might not have the slightest interest that others benefit from their work anyway, which makes it unlikely that they use CFG in the first place.
If I would have written CFG I would use the GPL even for the libs to promote my own and other's free software. Commercial products are easily integrated into CFG, and can even easily make (regular) use of CFG thanks to published specs and available XML libs.
> 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.
I do not think there is a way to "force" vendors. And as I said before, I don't think "forcing" anybody other than yourself will ever have a positve effect.
> The trick is how to do this without scaring them off.
If they have an interest (like many users wanting support in the free CFG tools, just like many users wanted to have linux support) they just might. If they are not interested you are dead in the water, just don't let them take advantage of you.
Let's not get distracted from the rules that made free software successful in the first place. Help with free software, the GPL and a free society, at least keep a free reviewing mind.
cheers,
Peter
PS: I would like to stress that this is not an issue that can be dealt with just by concentrating on technical aspects. For those that can read german there is an excellent book about this subject out (Online version free or printed book for 2 EURO). http://freie-software.bpb.de
|
|
From: Richard S. <csa...@ui...> - 2003-11-14 15:36:42
|
On Fri, 2003-11-14 at 14:47, Jason Long wrote: > Your compile errors are with the Perl wrapper. Since the compile was ab= le to get this far, I think Justin is right that regenerating the config4= gnu_wrap.cxx file is the correct way to go. >=20 > I'd recommend the latest CVS version also. I don't think much has chang= ed, but I believe there were a few C++ compiling issues that were fixed. Hm, I checked out c4g from cvs and tried to compile, but it wouldn't work either. But i think there might be something wrong with swig. What Version of swig are you using?? mine is swig-1.3.19 Over the weekend I'll try it with my Desktop-PC which runs Slackware9.1 maybe this is a better Environment to get c4g running, because ydl seems to be rather outdatet. -Richard btw. this is the error message. -- make[3]: Wechsel in das Verzeichnis Verzeichnis =BB/home/oracle/Downloads/c4g/config4gnu/src/wrappers/perl5=AB swig -c++ -perl5 -shadow -v -o config4gnu_wrap.cxx ../config4gnu.i LibDir: perl5 ./ /usr/lib/swig1.3/perl5/ ./swig_lib/perl5/ /usr/lib/swig1.3/config/ ./swig_lib/config/ /usr/lib/swig1.3/ ./swig_lib/ Preprocessing... /usr/lib/swig1.3/perl5/std_map.i:8: Unable to find 'std_common.i' make[3]: *** [config4gnu_wrap.cxx] Fehler 1 make[3]: Verlassen des Verzeichnisses Verzeichnis =BB/home/oracle/Downloads/c4g/config4gnu/src/wrappers/perl5=AB make[2]: *** [all-recursive] Fehler 1 make[2]: Verlassen des Verzeichnisses Verzeichnis =BB/home/oracle/Downloads/c4g/config4gnu/src/wrappers=AB make[1]: *** [all-recursive] Fehler 1 make[1]: Verlassen des Verzeichnisses Verzeichnis =BB/home/oracle/Downloads/c4g/config4gnu/src=AB make: *** [all-recursive] Fehler 1 |
|
From: Jason L. <JL...@me...> - 2003-11-14 13:47:38
|
Your compile errors are with the Perl wrapper. Since the compile was able = to get this far, I think Justin is right that regenerating the config4gnu_w= rap.cxx file is the correct way to go. I'd recommend the latest CVS version also. I don't think much has changed, = but I believe there were a few C++ compiling issues that were fixed. Jason >>> Justin Yackoski <ju...@sk...> 11/13/03 11:13:25 PM >>> I would suggest trying to latest CVS version if 0.1.8 doesn't work for = you, unfortunately I can't figure out what the problem is here. If you do = a checkout of CVS, you'll also need to install SWIG, which will then = re-generate the .cxx file its erroring on, which may fix your problem. Jason do you have any ideas? (sorry for not getting back to you until now btw) Justin On 11 Nov 2003 08:01:20 +0100 Richard Spindler <csa...@ui...> wrote: > Hi, > I tried to compile Version 0.1.8 of config4gnu, but it stopped with > the following error message: >=20 > -- >=20 > 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 >=20 > -- >=20 > 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 >=20 > Is there something I can do about this? > Should I give the CVS-Version a try? >=20 > regards > Richard >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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/=20 > _______________________________________________ > Config4gnu-developer mailing list > Con...@li...=20 > https://lists.sourceforge.net/lists/listinfo/config4gnu-developer=20 >=20 >=20 --=20 SkiingYAC Custom Solutions http://www.SkiingYAC.com=20 |
|
From: Justin Y. <ju...@sk...> - 2003-11-14 04:14:10
|
I would suggest trying to latest CVS version if 0.1.8 doesn't work for you,= unfortunately I can't figure out what the problem is here. If you do a ch= eckout of CVS, you'll also need to install SWIG, which will then re-generat= e the .cxx file its erroring on, which may fix your problem. Jason do you have any ideas? (sorry for not getting back to you until now btw) Justin On 11 Nov 2003 08:01:20 +0100 Richard Spindler <csa...@ui...> wrote: > Hi, > I tried to compile Version 0.1.8 of config4gnu, but it stopped with > the following error message: >=20 > -- >=20 > 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 >=20 > -- >=20 > 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 >=20 > Is there something I can do about this? > Should I give the CVS-Version a try? >=20 > regards > Richard >=20 >=20 >=20 >=20 > ------------------------------------------------------- > 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 >=20 >=20 --=20 SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Justin Y. <ju...@sk...> - 2003-11-13 17:46:31
|
Damien Uern said: >> >> 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. Well, I certainly agree that it would be stupid to care. Its just that I wouldn't be surprised if a few vendors did for whatever oddball reason. One thing they might have an issue with is the context-sensitive help that can be included in the meta-config files (again, yes that would be stupid). I guess as long as they can keep the copyright and maybe sign it with GPG or something, then they'd be happy? I don't know. > Why even bother thinking about licenses for the meta data > files? > I don't see why anyone cares. Its just that if we're going to let vendors use CFG libraries, then maybe we want to make them let other people use the support they add to the CFG libraries? Obviously they have to give people the source code to the meta-config files since its all XML, but other people (distros, a central CFG repository, etc.) may not be able to distribute them. Maybe you're right, and it doesn't really matter. Its just that this is what I saw as the "biggest" problem with staying LGPL. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Justin Y. <ju...@sk...> - 2003-11-13 17:23:11
|
We could use many of the .conf files that exist in the test/parsers/ directory to get us started. Some of the very generic ones wouldn't necessarily be included, but a few (samba, apache, passwd, group, shadow) are ones I basically copied off my system. I'd also suggest that any others submitted should be added to the parser testing system so that we can always validate that those files continue to work. Maybe it would be good to get copies of all the config files that are installed during the standard install of various distros (I imagine this is why Jason is asking for submissions). So, if you run something other than Gentoo and installed your app via a rpm/package/etc., I say submit it and give it a filename that designates the distro, distro version, and whether its the stock file or you've customized it (both are helpful) For example: Redhat-9.0-Stock-Samba.conf or Mandrake-9.0-Custom1-Samba.conf Then, we could modify the main XML file to have a "Sample Config Files" node and a "Your System" node so people can try either. Jason Long said: > 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 > > > > ------------------------------------------------------- > 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 > > > -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: <p.c...@ar...> - 2003-11-13 16:42:28
|
Hi, where is the file format for meta-config definitions defined? Because this might be interesting: ----- Original Nachricht ---- Waldo Bastian (bastian (at) kde org) 13.11.2003 17:18 Re: kconf_update -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu November 13 2003 16:38, you wrote: > Hello Bastian, > > I read the KDE feature plan, and stumbled over this: > > Give kconf_update the ability to filter generic, non-KConfig files. Waldo > Bastian <ba...@kd...> > > Maybe you already know, but if not, it might be very intersting! There is a > simple and generic framework called CFG (or config4gnu for long) that might > be good help. We can offer an easy way to manipulate general system > settings and more. Yes, I read something like that. Do you have more info about the format that you use for meta-config information? For KConfig we started using an XML format for that as described by http://www.kde.org/standards/kcfg/1.0/kcfg.dtd Cheers, Waldo - -- ba...@kd... -=|[ SUSE, The Linux Desktop Experts ]|=- ba...@su... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE/s67UN4pvrENfboIRAsGNAKCDbxim5vNf3vh5aamBPJ8AOcz4XQCgqttp MS7opnZVfOqOTLSRF9BlZT4= =ibd4 -----END PGP SIGNATURE----- |
13 messages has been excluded from this view by a project administrator.
