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: Christian L P. <pe...@co...> - 2003-04-10 12:39:11
|
I suffer from the "give me a Red Hat rpm" syndrome. Since there isn't a quick and dirty gtkmm rpm for the version you guys require I tried using the --disable-gtkmm. But configure still wants glibmm. Which, correct me if I am wrong, is part of gtkmm. You guys mentioned removing this as a dependency. Is easy for you guys to do? The gtkmm build requires a lot of dependencies that suck for a Red Hat box. Sorry I am extremely lazy when it comes to building from source. With this dependency out of the way is there anything else configure wants that Red Hat doesn't have in there distrobution? Makes me wish I still had Gentoo install on my laptop. Maybe today I will install it on another machine. BTW: Is the Libconf project still something you guys are planning on working with? And what happened with the Unixconfig project? -- Christian Pearce www.commnav.com |
|
From: Jason L. <jl...@me...> - 2003-04-04 18:57:21
|
Booleans appear to be working now. Thanks. Jason >>> "Justin Yackoski" <ju...@sk...> 04/04/03 09:55 AM >>> Jason Long said: > Justin > > How do you feel about switching the attribute with the element content > for boolean values... i.e. > > <value booleanvalue="yes">true</value> <snip> > And if we would make that change, I suppose a change in the name of the > attribute would be necessary also > > e.g. <snip> > <value literal="yes">true</value> > I've committed the changes to CVS. You only need to change the true/false value, the literal attribute is just used to determine what format to use to write out the boolean, and all samba booleans have default values literal attrs, so I'm fairly confident it will work although I can't test the GUI at the moment. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com ------------------------------------------------------- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ _______________________________________________ Config4gnu-developer mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/config4gnu-developer |
|
From: Justin Y. <ju...@sk...> - 2003-04-04 14:50:23
|
Jason Long said: > Justin > > How do you feel about switching the attribute with the element content > for boolean values... i.e. > > <value booleanvalue="yes">true</value> <snip> > And if we would make that change, I suppose a change in the name of the > attribute would be necessary also > > e.g. <snip> > <value literal="yes">true</value> > I've committed the changes to CVS. You only need to change the true/false value, the literal attribute is just used to determine what format to use to write out the boolean, and all samba booleans have default values literal attrs, so I'm fairly confident it will work although I can't test the GUI at the moment. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Jason L. <jl...@me...> - 2003-04-04 01:33:43
|
Justin How do you feel about switching the attribute with the element content for boolean values... i.e. <value booleanvalue="yes">true</value> Although it is easy for me to make the CheckBox class display and toggle the booleanvalue attribute, it has occurred to me that other widgets that don't know how to deal with boolean values are going to display the wrong information (e.g. the property list). If we say the content of the value element is the real value and the attribute on the value tag is purely for the parser/unparser, it would make things a lot more consistent. And if we would make that change, I suppose a change in the name of the attribute would be necessary also e.g. <value booleantype="yes">true</value> or <value literal="yes">true</value> Let me know your opinion on this. Meanwhile I'll keep considering how the type information could say that the "value" for the boolean type is the booleanvalue attribute. If that can be done, then changing this won't be necessary. Jason |
|
From: Justin Y. <ju...@sk...> - 2003-03-28 15:10:42
|
I've elaborated on the API & updated the permissions. Let me know if there's anything else you think should change: http://config4gnu.sourceforge.net/docs/implementation/middle.html Justin Jason Long said: > Can you elaborate a little more on how the parsers have to go through > the middle layer's API to read/write subsequent files? Specifically, > names of functions and what parameters they need.... > > Everything else looked good, although I also want to comment on file > permissions of the cached copy of the XML. I would vote for making the > cache copy automatically 600. This way we don't have the situation that > arises in your example, that when the main file has less restrictive > permissions than an include file, you cannot access the info stored in > the include file by reading someone's cache file. > > Jason > >>>> Justin Yackoski <ju...@sk...> 03/25/03 19:46 PM >>> > Jason, > > I added a "File Access & Caching" section to the implementation guide > for the middle layer. I put it in the middle layer since I think it > will be better written in C++, and so that parsers in other languages > won't need to rewrite it, nor will Perl need to be loaded for cache > hits. If you think it looks good, I should be able to implement both > the C++ and Perl components of it in the next week. > > Let me know what you think. > > Justin > > -- > SkiingYAC > Custom Solutions > http://www.SkiingYAC.com > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Config4gnu-developer mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/config4gnu-developer > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Config4gnu-developer mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/config4gnu-developer -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Jason L. <jl...@me...> - 2003-03-28 04:00:07
|
We're thinking about implementing a bunch of things for a presentation in
two weeks. One thing I'd like to get done is a sample script of showing how
you can read and manipulate configuration settings in Perl using the
Config4GNU library.
How about something like this for a demo? It reads and changes the WINS
server setting in the Samba configuration file.
~Jason
#!/usr/bin/perl
use config4gnu;
# open Samba configuration
$samba = config4gnu::get_configuration("App::Samba::Default",
"/etc/samba/smb.conf");
# examine current WINS server setting
$wins_server = $samba->get_child("global")
->get_child("wins_server");
print "WINS server is ",
$wins_server->get_value, "\n";
# change WINS server
$wins_server->set_value("192.168.1.10");
# commit changes
$samba->save;
|
|
From: Justin Y. <ju...@sk...> - 2003-03-26 04:10:25
|
On Tue, 2003-03-25 at 20:38, Jason Long wrote: > Justin, > > I'm attaching what I have so far, for you to take a look at. Some of it is > repeat of stuff that's already implemented or discussed. A few questions/suggestions: - In the identifier, could we drop the .type or make it optional? i.e., config4gnu.sourceforge.net/samba-config#samba-share, or maybe even just do samba-config#samba-share and if no top level is specified then config4gnu.sourceforge.net is assumed? Not sure if this would cause a problem, just wondering about saving some extra typing. - If I reference config4gnu.sourceforge.net/samba-config.type#samba-share, do all of samba-config.type's types get loaded, or just samba-share? - Is there a way to include another type definition from within a .type file, i.e., trigger the load_type_definition_file function? - If I extend a type, I assume its type file gets parsed, and I assume it must be specified by its ID. Do all the types in that .type file get added to the current list of available types (so that they can be referenced as if they were types in the current file), unless of course they're overridden in the current .type file? - I assume that if the current type file has a type that it would never be over-ridden by anything which is extended, included, or referenced within that type definition file? I could understand if including were required to be done first, and maybe even extending, but referencing causing overriding would be a problem. I'll modify the things you suggested about my proposal. My only question is who should the owner of a file be? The current user I assume (and maybe root in the case of an eventual system-wide cache directory)? Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Jason L. <jl...@me...> - 2003-03-26 01:38:49
|
Justin, I'm attaching what I have so far, for you to take a look at. Some of it is repeat of stuff that's already implemented or discussed. Jason |
|
From: Jason L. <jl...@me...> - 2003-03-26 01:32:16
|
Can you elaborate a little more on how the parsers have to go through the middle layer's API to read/write subsequent files? Specifically, names of functions and what parameters they need.... Everything else looked good, although I also want to comment on file permissions of the cached copy of the XML. I would vote for making the cache copy automatically 600. This way we don't have the situation that arises in your example, that when the main file has less restrictive permissions than an include file, you cannot access the info stored in the include file by reading someone's cache file. Jason >>> Justin Yackoski <ju...@sk...> 03/25/03 19:46 PM >>> Jason, I added a "File Access & Caching" section to the implementation guide for the middle layer. I put it in the middle layer since I think it will be better written in C++, and so that parsers in other languages won't need to rewrite it, nor will Perl need to be loaded for cache hits. If you think it looks good, I should be able to implement both the C++ and Perl components of it in the next week. Let me know what you think. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Config4gnu-developer mailing list Con...@li... https://lists.sourceforge.net/lists/listinfo/config4gnu-developer |
|
From: Justin Y. <ju...@sk...> - 2003-03-26 00:43:28
|
Jason, I added a "File Access & Caching" section to the implementation guide for the middle layer. I put it in the middle layer since I think it will be better written in C++, and so that parsers in other languages won't need to rewrite it, nor will Perl need to be loaded for cache hits. If you think it looks good, I should be able to implement both the C++ and Perl components of it in the next week. Let me know what you think. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Justin Y. <ju...@sk...> - 2003-03-11 03:10:50
|
I've rebuilt everything from CVS and the parsers seem to be working fine
(make check in test/parsers is successful), but when I run
src/wrappers/perl5/test_CfgObjectVector.pl, the script dies on line 19.
The gtkmm client is working fine for me. But, when I try to run the php
client, I get:
CfgBackendObject.cc:144: class CfgPropertyDefinition
CfgBackendObject::get_property_definition() const: Assertion
`property_type != __null' failed.
Relevant Backtrace:
#3 0x4055ec09 in __assert_fail () from /lib/libc.so.6
#4 0x40c70e92 in CfgBackendObject::get_property_definition
(this=0x82b6c10) at CfgBackendObject.cc:144
#5 0x40c74dd2 in CfgObject::get_property_definition (this=0x82b6d10) at
CfgObject.cc:104
#6 0x40c7660f in CfgObject::get_path (this=0x82b6d10) at
CfgObject.cc:382
#7 0x40719708 in _wrap_CfgObject_get_path (ht=0,
return_value=0x82b9dfc, this_ptr=0x82b9cdc, return_value_used=1)
at config4gnu_wrap.cxx:781
I can't figure out what is causing either problems to occur. It doesn't
seem like either is being caused by it not being able to find a library
or xml file...
Justin
--
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com
|
|
From: Justin Y. <ju...@sk...> - 2003-03-04 12:52:14
|
Jason & all others watching this list, Here is a list of bugs and things that we want to get done very soon. All are welcome to contribute by implementing or fixing any of these things! BUGS: - segfault when no class definition file is found, should give informative error instead - boolean values in Samba config files (and probably INI and apache style also) can have mixed case. How do we handle this? Its easy to just convert it to lowercase and try as best as possible to preserve the capitalization during saving, but how can we tell that the option is boolean so we know we should convert it? FEATURES: - Delimited::Colon should handle secondary delimiters better, and allow them to be set on a per-field basis. - Overlib javascript popups should be used (or an available option at least) to display context sensitive help in PHP client - How to preserve state between PHP page loads? (so we don't have to reparse everything to make each pagea?) - Add Functions in libconfig4gnu to return properties, sections, sections and properties (preserving order), or "value" tags such as comment, name, value, etc. - Add xforms for things like the passwd file, etc. - Add Apache and ProFTPd parser (by extending Common::Apache) and add class definitions and xforms for them. - Write MAN page (& other docs) to XML parser so we can add docs very easily. - Write Util::XMLDump parser (which just loads/saves XML) - Better error handling/message passing b/t parser & libconfig4gnu. Many of these things are pretty self-contained and would be a great place to start if you want to get involved. If anyone starts working on any of these things, please send a message to the list so we know not to work on it. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Jason L. <jl...@me...> - 2003-02-08 05:32:56
|
Yes it was good to hear something on your mailing list recently after being quiet for a while. I've been meaning to see what's happening with the libconf project, but haven't gotten around to it yet. We'll take a look in this upcoming week and see what the possibilities are. Jason |
|
From: <da...@id...> - 2003-02-08 00:51:39
|
Hi! I'm the main developer of libconf, we already talk together some times ago. I'd like to see if there is now a better oportunity to work together. On the libconf side, the library is fully functionnal with numerous templates. I'm now coding the high level API. But I think it could be a good time to code a "plugin" in libconf to generate an xml tree of the config file structure, compatible with config4gnu, to allow you to use libconf. Tell me if you are interested. libconf is now on savannah.gnu.org : http://www.nongnu.org/libconf/ The version 0.11 is downlodable, both tarbal and as mandrake rpm. see you, -- dams |
|
From: Jason L. <jl...@me...> - 2003-02-07 14:54:25
|
Justin, nice work on the apache-style parser. Now to get the unparser working... I want to get in the habit of going over patches before they get committed. This will help us both to stay in tune with changes as they happen and perhaps find problems in each other's code. The attached patch allows you to specify in the property definition that the "property name" should be the "name" property of the property instead of the name as specified in the property definition. Jason |
|
From: Jason L. <jl...@me...> - 2003-02-05 15:29:24
|
Config4GNU, a project to provide a single unified interface to system configuration data on Linux computer systems, is still quite active. A lot has happened since the last news update, including the writing of a new implementation guide, using a new XML library, and finding a new way to do scripting language bindings. In late November, all of December, and even some of January, a lot of work has been focused on an "implementation" document, which is a guide for how various parts of the system will work and how they fit together. It is a more detailed document than anything we have done so far. Understand that it is a constant work-in-progress; there are many parts that are out of place, inconsistent, or already out-of-date as the project changes. It can be viewed at http://config4gnu.sourceforge.net/docs/implementation/. In addition, out of an interest in using an XML parser that supported XML schema, we switched to the Xerces XML parser, available at http://xml.apache.org. It is written in C++, which required us to rewrite the client in C++. This turned out to be a great improvement. Both Justin and I have found that writing the code in C++ is easier to read and to create new things. Finally, only recently we came across SWIG (http://www.swig.org), which is a program that automatically generates bindings for many scripting languages, including Perl and PHP. Using SWIG as part of the build process allows us to easily keep the Perl and PHP bindings always up-to-date. |
|
From: Justin Y. <ju...@sk...> - 2003-02-01 21:53:33
|
Jason Long said: > Justin, I just recently came across http://www.swig.org/, which has a > tool to automatically generate bindings for libraries written in C/C++ > to several scripting languages, including Perl and PHP. Have you ever > heard of this? Perhaps this will be a good way to do our bindings. Yeah, actually I came across it b/c swig was supposedly used to generate nearly all of the Xerces Perl bindings. I imagine thats how you found it as well. Using it would certainly make things simpler to at least get baseline bindings setup, and then we can customize it from there. I skimmed through their website, and its certainly something to look into. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Jason L. <jl...@me...> - 2003-01-30 18:59:51
|
Justin, I just recently came across http://www.swig.org/, which has a tool to automatically generate bindings for libraries written in C/C++ to several scripting languages, including Perl and PHP. Have you ever heard of this? Perhaps this will be a good way to do our bindings. Jason |
|
From: Justin Y. <ju...@sk...> - 2003-01-13 23:47:08
|
For those who watch this list (hopefully there are a few of you out there), Jason and I had a brief meeting yesterday where we discussed a few things: - the parser directory structure will be reworked to allow for directories specific to each distro vendor (debian, redhat, gentoo, etc.) and application (samba, apache, etc.) to provide a single place for these other groups to store (un)parsers specific to them. - we talked about supporting other distro-specific items. The other main one is file paths, which will be stored in distro-specific "master documents" which the GUI will actually load & save to edit the configuration. This allows file paths to vary, although it would be good to standardize this. - we also talked about supporting differing default values among distros, such as if a server is routinely compiled with a default other than the standard default, which would make any defaults stored in a schema file incorrect. We decided that such practice is not a good idea, and its not worth (at least at this point) having separate schema files to reflect it. The only catch is what to do about different *versions* of applications which may have different behavior that results in a different schema. Perhaps this will be handled by version-specific schemas? - We came up with a basic idea on how the parsers will interact with the rest of the system in the area of caching and "instance metadata". Instance metadata are things like CFG-generated access controls and other items which apply to specific configuration directives. We decided to store this in the actual XML cache of the native config files. This will mean that if a configuration directive or section is removed by the user, the metadata will also be removed (or reset to the defaults), which is desirable. When a new XML representation is generated by the parser, an updater routine will need to combine the cached metadata with the new config data. - Finally, we discussed a timeline for the near future: By the end of January (approximate) have CFG ready for others to write parsers and meta files needed to add support for various apps/distros, and have basic library finished so people can begin on other clients. To accomplish this, we have to: 1) cleanup parsers 2) get dynamic loading working in C++ version using Xerces 3) split out CFG library from C++ client (so other clients can use it) 4) have working CRUD (create, read, update, delete) functionality for client and library 5) publish docs on "finalized" schema files and metadata formats Then, we will work on adding support for new things (and encouraging others to help!), and start adding support for more things, including: 1) web-based client (PHP and/or perl) 2) command line client 3) refine metadata (if necessary) & create more of it (docs, etc.) 4) implement caching to provide speed boost 5) logging 6) rollback/undo mechanism 7) advanced authentication/access control system 8) remote administration and way to copy config from one system to another If anyone wants to help at this point, you are welcome to. Right now, we would like to work on the first list given above (and not on the second). It may be difficult for many people to work on it at this point, but if you are interested in writing some quality code for specific parts based on specific requirements, we can probably work something out. After the first list is done, we'll be able to really solicit help (which is why we want to finish the first list!). If anyone has any questions/comments/suggestions, they are more than welcome. I didn't go into great detail on all of the things Jason and I talked about, so some things may not make sense. I think I covered everything but I might have left something out. Finally, Jason, I'm working on the runlevel parsers and it *seems* like your XML format isn't 100% consistent between the two (which may be necessary), but I may be reading it wrong. I've also got a few questions for you on how the parsers should work since your runlevel parsers make slightly different XML than the library-based parsers. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Justin Y. <ju...@sk...> - 2003-01-05 18:18:19
|
Jason Long said: > Justin > > I'll put a copy of the graphic file into your upload folder. I suppose > we should file a bug report on Dia that there is no way to convert a > .dia file to .png without X-windows. Looks like they're working on it: http://bugzilla.gnome.org/show_bug.cgi?id=58196 Apparently it was needed to get fonts until they switched to Freetype, and now its just old code causing the problem. There's an ugly workaround at http://www.lysator.liu.se/~alla/dia/faq.html#NoXConverting in case anyone is interested. In any case, I uploaded the png you made. > As for the C++ client, I forgot to commit some of the data files. Oops. > It should be fixed now. The crash you mentioned would happen because the > glade file was not at the location it mentioned. It looks like you > configured your prefix to be /usr/local and did not "make install". If i set the prefix to anything other than /usr/local/, I get: libtool: install: error: cannot install `libconfig4gnu.la' to a directory not ending in /usr/local/lib Not a big deal, just wondering if it is supposed to give me that (since before I think that lib installed just fine in /tmp/cfg/ As for the actual program, it seems nice & fast (hard to tell over remote X though). I loked at the samba-config.xml file. I know before you mentioned that it was a sort of Schema. It looks like the meta-data file we discussed at one point which will contain the information not in the actual Schema file, but with some extra Schema stuff. So if I undrestand this correctly, evenually samba-config.xml file will be split into a real Schema file and another file that contains human-readable information (docs, etc.)? > The question about bindings is a good one. I think it will be ok, but as > of now I don't know how that's going to work. I think it involves > declaring a function as being a "C function" then doing the C++ stuff > inside the function. OK, just checking. So, should we write everything in C++, or some in C, some in C++? I assume we will want to create C bindings for our libraries which provide the API for CFG, so I guess if we do that, we can then just use those bindings when we make PHP & other extensions that require C. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Jason L. <jl...@me...> - 2003-01-04 18:31:07
|
Justin I'll put a copy of the graphic file into your upload folder. I suppose we should file a bug report on Dia that there is no way to convert a .dia file to .png without X-windows. As for the C++ client, I forgot to commit some of the data files. Oops. It should be fixed now. The crash you mentioned would happen because the glade file was not at the location it mentioned. It looks like you configured your prefix to be /usr/local and did not "make install". The question about bindings is a good one. I think it will be ok, but as of now I don't know how that's going to work. I think it involves declaring a function as being a "C function" then doing the C++ stuff inside the function. Jason |
|
From: Justin Y. <ju...@sk...> - 2003-01-04 17:23:14
|
Andreas Jellinghaus said:
> Hi Justin,
>
> thanks a lot. Now i see a lot clearer what you are doing.
>
> About using your library in applications:
>
> use Config::IniFiles;
>
> my %config;
> tie %config, 'Config::IniFiles', ( -file => $ARGV[0] );
>
> $config{Package}{Name} = $pkg;
>
> if ($config{Package}{Name}) ...
>
> tied( %config )->WriteConfig( $file )
> or die "Could not write config to $file: $!";
>
> This is what I'm currently using in perl.
> I'd love to switch to something more powerful, as Config::IniFiles has
> several limitations: exactly two levels (section/tag), no
> multiline values, only available in perl.
>
> But by far I have not seen anything that is as easy to use and
> needs a comparable amount of code. What about adding some example
> code to the web page? I looked at using raw glib and libxml,
> but in the current state it's far too much work/code to write.
Certainly there are limited config libraries for applications. While we
do plan to address this, we don't have any production-worthy code at the
moment (hence no sample code on the website). If you want to see how our
parsers currently work (we will probably switch them over to Xerces' perl
API soon), you can checkout config4gnu from CVS, then look in
config4gnu/src/parsers/ for a README file and a parserfunction.sh If you
source parserfunction.sh ( by running: . ./parserfunction.sh ), you can
then do:
testxmlparse /path/to/yourconfigfile Ini
or
testxmlparse /path/to/yourconfigfile Type::SubType
and you'll get an XML output of your config file. For now, you pipe that
output to another program which reads XML (such as a perl script using
DOM) and access the data that way. In the future this step will be
handled for you. Again, this code is working as far as we can tell, but I
can't guarantee it. The method of using our code will also likely change
soon, (when we create a better API).
Read the README file for more details on customizing & using the parsers.
If you would like to contribute to development, such as converting them to
Xerces-perl, or working on our main library's API for applications to read
their configuration files (which will replace the messy way I explained
above), or anything else, let me know.
Justin
--
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com
|
|
From: Justin Y. <ju...@sk...> - 2003-01-04 05:04:08
|
Claes Holmerson said: > Hi! > > After reading through the documentation on CFG, I think there are some > shortcomings in the way the "configuration hierarchy" is described. The > documentation, examples and screenshots illustrate a number of daemons > and below them you show Apache, Samba, Mysql etc, and below that is the > actual configuration. However, have you considered the case where there > is a number of different instances running of same daemon? It is very > possible to run several Apache servers at once, on different ports. In > other words, there should be a one-to-many relation between a specific > type of configuration (such as Apache configuration), and instances of > files of this type/configurations of this type. This leads me to a > second > suggestion: please allow for configuration files to be located anywhere > in the filesystem. Do not assume that files should be located strictly > in /etc for example. The configuration will be loaded by the UI by opening a master XML document. This will be a "virtual" XML document, because it will refer to various other XML documents, some of which don't even exist (they will be created on demand by parsing native config files). Using this approach, it will be possible to create 2 copies of Apache's configuration, or even move Apache's configuration into a new section (perhaps "beta servers" instead of "daemons") if you so desire, and also allow renaming the node to "Apache Test Instance 1" or whatever. The files which the master XML document refers to will contain the actual paths to the config files (if they want to over-ride any default path), so your second suggestion will also be possible. > So in other words, please design CFG to be scalable in both directions: > both to manage a single configuration of a certain application on many > machines AND managing multiple configurations of a certain application > on a single machine. Agreed, we will do our best :) > It would also be very valuable if metadata could be stored for every > configuration "entity" (such as a configration file). An example of very > useful metadata to attach to a certain configuration file is the command > to stop and start the application related to it. Such metadata would tie > the configuration together with the application, and allow you to easily > start, stop and restart the application related to the specific > configuration file from the configuration gui. We definitely want to be able to include (perhaps optional) information regarding how to stop/start/reload a daemon, any external syntax validator programs, how to tell if the daemon is running, relevant documentation, etc, etc. Metadata is very important & we'll make adding more as easy as possible, since we realize that without metadata, we're really not accomplishing as much as we could. > I think CFG looks promising. I look forward to following the progress! We appreciate your input. If you would like to contribute in any way, we're about to really start focusing on coding & welcome any type of help. Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Justin Y. <ju...@sk...> - 2003-01-04 04:41:06
|
Jason Long said: > Justin > > There are some sections that I had recently committed to > implementation.sgml that did not make it in the XML version. Can you > check this and make sure they get put in? Sorry about that, I thought I had gotten the latest version from CVS, but I guess I didn't. Its all there now. The only thing is that for some reason dia won't make objects.png without opening an X window (even if I disable the splash screen), and it crashes when I try to use X-Win 32. So, right now there's a randon png (gtk.png) in its place. If you could drop it on my PC someplace in a directory you have access to, I'll put it on the website. Its not a big deal though, it can wait til the 7th. > I have committed the C++ client. Make sure to "emerge gtkmm" and "emerge > glademm". Then download Xerces-C++ and build it somewhere. Finally, look > in our source tree's README file for further instructions. The client is > in config4gnu/src/clients/gtkmm. The client, if you get it to compile > and run, will load a sample Samba configuration file that I wrote. I emerged gtkmm and libglademm (not glademm) & built Xerces and it compiled just fine. It ran w/ my test samba file from the parsers (I didn't see your test one, if I was supposed to be using it...). I managed to crash it when I clicked on one of the "string" entries in the right side, and got: (gtkmm-cfg:24693): libglade-WARNING **: could not find glade file '/usr/local/share/config4gnu/gnome-cfg.glade' I assume this is b/c one of my environment variables wasn't pointing to src/gnome-client/gnome-cfg.glade > Note also that I kind of invented my own XML description system that is > much simpler than XMLSchema and much easier for me to implement and get > working :). Of course it is also not nearly as expressive as XMLSchema. > It is something to get us started with though. Look in > config4gnu/data/classes/samba-config.xml. I'm not finding this file either... I can see your old files in classes/ but nothing since Nov 11. I've also browsed through most of your new code in config4gnu/src/clients/gtkmm/. Here's a question... Assuming now that most of our code will be in C++, how hard will it be to write bindings in something like PHP for it, since PHP is written in C? Justin -- SkiingYAC Custom Solutions http://www.SkiingYAC.com |
|
From: Jason L. <jl...@me...> - 2003-01-03 23:47:15
|
Justin There are some sections that I had recently committed to implementation.sgml that did not make it in the XML version. Can you check this and make sure they get put in? I have committed the C++ client. Make sure to "emerge gtkmm" and "emerge glademm". Then download Xerces-C++ and build it somewhere. Finally, look in our source tree's README file for further instructions. The client is in config4gnu/src/clients/gtkmm. The client, if you get it to compile and run, will load a sample Samba configuration file that I wrote. Note also that I kind of invented my own XML description system that is much simpler than XMLSchema and much easier for me to implement and get working :). Of course it is also not nearly as expressive as XMLSchema. It is something to get us started with though. Look in config4gnu/data/classes/samba-config.xml. Jason |
13 messages has been excluded from this view by a project administrator.
