config4gnu-developer — Config4GNU developers list

Re: [Config4gnu-developer] Basics of architecture

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

In response to:
Devin Jones <dev...@ya...> 10/21/02 17:27 PM


Yes, that's right. I couldn't have said it better myself. Do you have any
suggestions/criticisms?

I'm not sure yet what the contents of the descriptor file will be, but you
are correct that it will need to specify the commands to transform the file
from native to XML and back.

We could also provide ways for descriptor files to "extend" another
descriptor file. So, for example:

inifile descriptor file (example)
 - defines a "readcommand" to read the configuration file and generate an
XML
 - defines a "writecommand" to write the configuration from XML
 - defines that a configuration node of this type should contain a property
called "config file" that specifies the file that is to be parsed

samba descriptor file (we really like using Samba as an example)
 - it extends `inifile'
 - defines a default "config file" property of "/etc/samba/smb.conf"
 - defines descriptions, data types, and default values for properties
 - defines a "validate" command to check a configuration

As we work out these details, I want to post them to our "System
Requirements Specification", which is a document that attempts to describe
very precisely the various capabilities of the system.

The requirements specification is a Docbook-format file available in CVS
under website/docs/requirements/requirements.sgml. Justin has posted this to
the http://config4gnu.sourceforge.net website.

Jason

[Config4gnu-developer] Basics of architecture

[Devin J. <dev...@ya...>]

I just want to make sure I understand the basics here:

Transformations:
 Native config files -> in memory Tree of nodes
 Tree -> XML
 XML -> Tree
 Tree -> Native config files

Parsers read native config files and create a Tree of nodes. (Native -> Tree)
Parsers then write out XML file (Tree -> XML)

Config front-end reads XML file (XML -> Tree)
FrontEnd modifies settings.
FrontEnd saves changes (Tree -> XML)

UnParser (ConfWriter) reads XML (XML -> Tree)
UnParser then writes native config file (Tree -> Native)

Providing guidance for the transformations is the Descriptor file which
specifies what parser/ConfWriter is to be used and a set of Properties, types,
descriptions for a given native config file format/type.

Am I right so far?

Devin

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/

[Config4gnu-developer] project tasks/design proposal and thoughts on libconf

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

There are a number of people on the developer mailing list.  I encourage
any/all of you to respond to this message (and all messages on this list
for that matter) with your input.  Jason and I can't do this ourselves,
and I know many of you want to help.  If something isn't clear, it may
be one of those things me & Jason discussed face to face, so feel free
to ask if you're confused.

Part of this email is an attempt to document face to face communication
between me & Jason, and the rest is a transcript of conversations I've
had with myself in the past few days... :)  I welcome any & all
clarifications & disagreements, I certainly don't claim to have all the
answers.


Proposed Design/Tasks plan:

Stage 1) Finish design of XML and decide on standard format/tags for
it.  Make at least 1 parser and GUI which can handle this XML properly
for demo purposes.  The middle layer is mostly a dummy layer at this
point.  At the end of this stage, we've got a working program, but it is
considered beta and lacks a lot of important/fancy features.  Target:
Dec 2002 - Jan 2003.

Stage 2A) Develop each layer more or less independently of eachother. 
We would add maybe one or two more front-ends, parsers for most config
files, and incorporate context-sensitive documentation inside the
front-ends for *each* configuration directive, as much as possible. 
Some of this can be accomplished by parsing man pages, etc.

Stage 2B) Possibly independently of 2A, this stage involves adding
"required" features to the middle layer.  Things like checking to make
sure that the user's configuration is sane, adding logging and undo
features, adding support for applications/daemons to read their
configuration as XML via our libraries (instead of parsing them
themselves).  At the end of this stage, we've got a 1.0 release. 
Target: Early-mid Spring 2003 (March?).

Stage 3) Improve stability and speed, smooth over any rough edges not
already taken care of in the design of everything.  At the end of this
stage, we should be ready for a 1.2 release, and should really start
convincing distros & software maintainers to include our stuff.  Target:
early Summer 2003 (May?).

Stage 4) Add support for configuring many more things.  Provide
configuration data so C4G can handle all common things under GNU
systems.  Maybe add library for programs to use C4G to access their
config files at this stage instead of in 2B.

Stage 5) Possibly add modules to existing configuration tools (webmin,
linuxconf, etc.) which allow those configuration tools to manipulate our
configuration data.  Not sure if this is really necessary, but its an
idea.

Stage 6) Maintain compatibility with current software as necessary,
although by this point we shouldn't need to do much at all.



Now, here are my thoughts on Libconf...

I think using Libconf could be a good thing, but I see the following
issues arising:

- C4G and Libconf should be packaged and released together, or at the
*VERY LEAST*, new releases should be synchronized.  My worry is that
especially during the early stages, we will be tweaking things a lot
(including the communication between layers/components), and this could
easily break things.  That would be a pain for testers during
development, and maybe even worse once C4G is ready for production
environments.

- XML should be used for communication using a standard XML structure. 
This allows things to be written in languages other than Perl without
much messyness.  Maybe we could even use a custom XML storage library
and write wrappers for it in the various languages so the XML doesn't
have to be re-parsed (Is this possible/worth it??)  

Anyway, I think only the parser/backend layer should be written at all
in Perl.  The rest (certainly the GUIs) should be written in C and
should be lean and fast, I can't stand slow GUIs (Nautilus comes to
mind...).

- It seems that developing C4G will require constantly revising the
middle layer as we need to.  If Libconf provides this layer, it could
easily end up being a bottleneck to get the Libconf developers to make
the changes (unless some of "us" become libconf developers?).  If we
provide the layer, libconf will also need to access & modify the code
frequently.  This presents a big problem.  

Two solutions are to 1) Make C4G handle front-end stuff, libconf handle
back-end stuff, and a third project handle middle stuff, or 2) libconf
makes the back-ends, C4G makes our front-ends, and each project develops
a middle layer separately.  

If we pick #1, then there are going to be a lot of "cooks in the
kitchen", and that may (or may not) cause some problems & differences of
opinion, resulting in forked code.  It may also be difficult for two
brand new and not fully working projects to depend on eachother for
certain parts...

If we pick #2, then we almost may as well write our own parsers to work
with our XML format instead of coercing libconf to write parsers that
work the way we want them to.  Are parsers *that* hard to just write
ourselves?  Is there any other possible option?  I don't want to
duplicate work, but I don't know what to suggest here.

- I'm still trying to understand what exactly libconf will provide and
how it differs from our project from a design standpoint.  I've read
most of the Libconf docs, but its still fuzzy, and I've yet to get ahold
of anyone online on IRC.  Note that this isn't necessarily the fault of
anyone responsible for Libconf.


Justin

-- 
SkiingYAC.com
Custom Solutions
su...@sk...
http://www.SkiingYAC.com

Re: [Config4gnu-developer] proposed changes to PHP mod

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

On Sat, 2002-10-19 at 11:03, Jason Long wrote:
> Justin here are some proposed modifications to the PHP extension. This will
> give you an opportunity to work with the new PHP code.
> 
> Modifications will be made to src/clients/php/zendmod.c
> 
> 1. Change name of c4g_get_top_node to c4g_get_root_node. Since we are using
> a tree hierarchy, I think this name would make more sense.

Done
 
> 2. Take the code that actually reads the top node from c4g_get_top_node and
> put it in the `module_init' function. Create a module-level static variable
> to hold the top node after initialization is complete and use it in the
> `c4g_get_top_node' function instead of loading a new tree.

Also done.  We still need to clean up module_uninit to fix that minor
memory leak.  I also checked into src/clients/php/ two files,
c4g.class.php and example.php.  The c4g.class.php is a new PHP class
wrapper around the c4g PHP extension, and the example.php is, you
guessed it, an example of how to use the class to output the exact same
thing your non-object-based test.php script did.  It seems slow, I'm not
sure whether its much slower than your script, but I'm gonna see if I
can speed it up.

Justin

-- 
SkiingYAC.com
Custom Solutions
su...@sk...
http://www.SkiingYAC.com

Re: [Config4gnu-developer] Transport Level ?

[Alexsandr M. <ale...@ba...>]

Hi.
> I'm thinking specifically of gnome-vfs, (see http://www.gnome.org/ and
> http://developer.gnome.org/doc/API/gnome-vfs/) but I know there are oth=
ers.
> Is a dependency on gnome-vfs a bad thing? Are there any other libraries=
 out
> there that could do this?

I think it's a bad idea, cause:
1) libgnome-vfs requires 27 different libraries to be installed in the sy=
stem=20
(at   least version installed at
   my home system), and i think it's no good for a system which aims to w=
ork=20
at different distributions.
2) we don't really need all the functionality of gnome-vfs (or kioslave o=
r=20
some other vfs system)
   , we just need something like a CUPS backends, specialized programs
   used to send/recieve configuration files, basing on URI.

I attached a small .eps diagram to illustrate how i see the transport lev=
el.

The algorithm is:

1. Middle level, basing on URI, fires up the specific transport (for exam=
ple=20
file transport for URI beginning with 'file:/').
2. Transport retrieves a configuration file(s) into some local configurat=
ion=20
cache (for example into: /var/spool/c4g/conf-cache/tmp.node231/...).
3. Middle level tells specific parser to process data from cache.

> Also consider this:
> The current implementation on CVS has the back-ends (the parsers) runni=
ng
> as separate processes from the front-ends. This allows the parsers to b=
e
> written in any programming language. Whatever transport layer it uses t=
o
> access the configuration files is up to that particular parser.

I don't feel it's a right thing to let parser know where
the configuration files are and to access them directly.
Parsers, imho, should access configuration located
in some local configuration cache and do not mess with a
distribution specific configuration file placement policy.

> -- FYI for readers in general: an explanation of parsers/unparsers
>
> parsers - read an application-specific configuration file and represent=
s it
> using an XML representation.
>
> unparsers - a rather bad term (how do you unparse?), but it takes the X=
ML
> representation and writes out the application-specific configuration
I consider "unparser" a bad term too, but i just don't know how
to express that kind of thing with a short term. Some suggestions ?

BR
    Alexandr Mikhailov

P.S.
    By the way, how do you see the middle level ?
    I think it has to be a server to implement a normal access-controls.

[Config4gnu-developer] proposed changes to PHP mod

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

Justin here are some proposed modifications to the PHP extension. This will
give you an opportunity to work with the new PHP code.

Modifications will be made to src/clients/php/zendmod.c

1. Change name of c4g_get_top_node to c4g_get_root_node. Since we are using
a tree hierarchy, I think this name would make more sense.

2. Take the code that actually reads the top node from c4g_get_top_node and
put it in the `module_init' function. Create a module-level static variable
to hold the top node after initialization is complete and use it in the
`c4g_get_top_node' function instead of loading a new tree.

If you look at the PHP manual, you'll notice that chapters 24-42 talk about
extending PHP. You may want to read them.

Jason

[Config4gnu-developer] creation of a PHP extension

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

I've done a bit of coding yesterday and today and I want to summarize what
I've done...

1. general configuration management code (the middle layer) has been
separated into a shared library (it had been part of gnome-client)
  config4gnu/src/libconfig4gnu

2. created a PHP extension in src/clients/php. It is a shared object, with
wrapper functions to convert PHP calls into Config4GNU calls. It allows a
person to write a PHP script that can access Config4GNU.

Please examine the PHP.txt file that's in the doc subdirectory of the source
tree for information regarding the PHP extension.

Location of PHP headers are hardcoded into the Makefile, so if you can't
compile check here first.

If you try this out and have difficulty, please let me know how you fare.
Also if you have comments....

--

Compiling and running Config4GNU

To run Config4GNU you must `make install' but you may not want to install to
/usr/local. Here's what I do on my system:

    ./autogen.sh --prefix=/tmp/c4g
    make
    make install

To run the program you must run from the src/clients/gnome-client directory,
since it looks for gnome-client.glade in the current directory.

    cd src/clients/gnome-client
    /tmp/c4g/bin/gnome-client

Best of luck
Jason Long

Re: [Config4gnu-developer] Transport Level ?

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

I think a transport layer is a good idea. It means the configuration
software installed on one system could help a person administer many
machines. Perhaps it could be achieved through an existing virtual
filesystem library?

I'm thinking specifically of gnome-vfs, (see http://www.gnome.org/ and
http://developer.gnome.org/doc/API/gnome-vfs/) but I know there are others.
Is a dependency on gnome-vfs a bad thing? Are there any other libraries out
there that could do this?

Also consider this:
The current implementation on CVS has the back-ends (the parsers) running as
separate processes from the front-ends. This allows the parsers to be
written in any programming language. Whatever transport layer it uses to
access the configuration files is up to that particular parser.

-- FYI for readers in general: an explanation of parsers/unparsers

parsers - read an application-specific configuration file and represents it
using an XML representation.

unparsers - a rather bad term (how do you unparse?), but it takes the XML
representation and writes out the application-specific configuration
--

~
Jason Long

[Config4gnu-developer] Transport Level ?

[Alexsandr M. <ale...@ba...>]

Hi all.

What about adding an underlying transport level into the c4g
architecture?

E.g.

 _________
|Frontends|
 ---------
 ____________
|Middle Level|
 ------------
 ____________________________
|Back-ends: parsers/unparsers|
 ----------------------------
 _____________________________________________
| Transport level: file, ftp, https, cvs .... |
 ---------------------------------------------

The transport level will be used to simply get/put original
configuration files to/from their original location.

It will make c4g network transparent, cvs aware e.t.c 

Good resource naming scheme will be required to make it work, (something
like bi...@my...net/myzonefile), but i think it worth it.

BR
	Alexander Mikhailov

Re: [Config4gnu-developer] Re: [libconf] libconf, config4gnu

[dams <da...@id...>]

Justin Yackoski <ju...@sk...> writes:


[...]

> 
> Certainly you have a much larger list of config files that our parses
> support.  We have one parser for ini-style files (Samba, PHP, etc.) and
> one for colon delimited files (passwd, shadow, group, etc.), which could
> easily be modified to parse other similarly-delimited files.  A question
> I have is whether your Samba parser also parses php.ini, and whether
> your Apache parser also works for ProFTP (which uses a *very* similar
> format).

yes, php.ini is supported by value_sections, and proftpd should work, I have
not tested. But I shortcuted the explanations. these templates are basic
templates, that is templates for a family of config file, not one. Then ames
are not very good, but the templates works for multiples config files. another
list is built from them at run time, a list of templates that are bonded to one
specific config file. I'll explain the stuff later. It's like major and minor
mode in emacs

>  We had been planning to create generic parsers that weren't
> aware of which directives were allowed in what sections, etc.

our templates (basic and specific ones) are _not_ aware of which directives are
allowed. That part is handled by the validation system, that is working, but
not like I would like to. I'll recode it shortly


>  This
> would allow a smaller number of parsers to be written and used.  

That's also the goal. For example, the comments will not be stored in the basic
templates, but in the specific ones. I'll code this next week-end if I'm lucky.

> 
> My second question is your reason for going with a perl data structure
> for passing the data.  Our system is built around XML to allow any
> language to interact with the data.  It wouldn't be hard to run the perl
> data through a script that made it into XML, but I'm just curious as to
> why you made that design decision.

there are 2 reasons, that are in the doc (go and read it :
http://www2.damz.net/files/libconf_doc.html
) :

-first one, I plan to use xml, but I build the core in perl. I have not build
 the xml stuff _yet_ but I will. But not shortly, because we don't need it now.
-the second one is that the software that uses libconf won't be obliged to grab
 the data ! It can get it, work with it, and give it to libconf, but libconf
 has a set of built-in functions to edit the data tree directly (documented at
 "features" in the doc). So when the C/python/whatever binding will be done,
 libconf will be fully useable, even if you don't have an xml parser (and you
 don't most of the time, when you are coding small config tools). So xml is
 good, but not needed.

> 
> Finally, we were planning on having a middle layer which was basically
> the brains of the whole thing (since both the parsers and the front-ends
> don't really know much about whats going on).  Am I correct in assuming
> that such a middle layer isn't provided by libconf?

It will be. It's the layer on top of libconf. Now if you want to code it,
you're welcome :)

> 
> I think a very important first step if we were to work together is to
> standardize the communication between libconf and c4g's components and
> stick to that standard.  We've developed a format for communication
> within c4g, but we'd certainly be open to suggestions/improvements.  I
> think the main thing is to have it be language-independent and to be
> general enough so that the front ends can easily understand it without
> having to be programmed to understand more than a small handful of XML
> tags or data structures.

well, libconf and config4gnu use perl, so I suggest that we have a fast way to
tranfer the data, by passing perl structure. We could discus on that structure.
The libconf one is not frozen now.

if you want, you can see us on #libconf@OPN

Re: [Config4gnu-developer] Re: [libconf] libconf, config4gnu

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

On Wed, 2002-10-16 at 12:08, dams wrote:
> "Jason Long" <jl...@me...> writes:
> 
> > I apologize for not responding earlier. I've been delaying because I haven't
> > really decided yet. :)
> > 
> > However, I think our projects do have slightly different scopes. Here's how
> > I would explain it, and be sure to correct me if I am mistaken.
> > 
> > libconf-
> >  provides a library for creating / manipulating a configuration file. It
> > will know about the different formats. The user has to specify what file the
> > configuration setting is in, but doesn't need to know about the internal
> > format of the file.
> > 
> > Config4GNU-
> >  tries to provide front-ends for accessing configuration settings for the
> > whole system. Settings from all sorts of different files will be accessible
> > through a hierarchical data model. Users who want to make a setting change
> > don't need to know what file it's actually stored in or what the format of
> > the file. However, Config4GNU must know about the file and what format it's
> > in.
> 
> 
> well, that would be true if libconf was alone :)
> But libconf is only a layer, another layer will be built on top of it, to
> abstract the location and the unicity of the information.
> 
> > 
> > That said, I think there's a great opportunity for collaberation here. The
> > way I see it, libconf could provide all of the parsing of and manipulation
> > of configuration files for Config4GNU.
> 
> ok, why not :)
> right now the templates supported are :
> 
> XF86Config
> Sshd
> Samba
> Shell (a tons of files are supported with this template then)
> Apache
> Values_section (idem, this is a generic template)
> 
> I think we are moving faster than you on the first layer, maybe it would be
> good that config4gnu provides the upper layer

Certainly you have a much larger list of config files that our parses
support.  We have one parser for ini-style files (Samba, PHP, etc.) and
one for colon delimited files (passwd, shadow, group, etc.), which could
easily be modified to parse other similarly-delimited files.  A question
I have is whether your Samba parser also parses php.ini, and whether
your Apache parser also works for ProFTP (which uses a *very* similar
format).  We had been planning to create generic parsers that weren't
aware of which directives were allowed in what sections, etc.  This
would allow a smaller number of parsers to be written and used.  

My second question is your reason for going with a perl data structure
for passing the data.  Our system is built around XML to allow any
language to interact with the data.  It wouldn't be hard to run the perl
data through a script that made it into XML, but I'm just curious as to
why you made that design decision.

Finally, we were planning on having a middle layer which was basically
the brains of the whole thing (since both the parsers and the front-ends
don't really know much about whats going on).  Am I correct in assuming
that such a middle layer isn't provided by libconf?

I think a very important first step if we were to work together is to
standardize the communication between libconf and c4g's components and
stick to that standard.  We've developed a format for communication
within c4g, but we'd certainly be open to suggestions/improvements.  I
think the main thing is to have it be language-independent and to be
general enough so that the front ends can easily understand it without
having to be programmed to understand more than a small handful of XML
tags or data structures.
 
Justin

[Config4gnu-developer] Re: [libconf] libconf, config4gnu

[dams <da...@id...>]

"Jason Long" <jl...@me...> writes:

> I apologize for not responding earlier. I've been delaying because I haven't
> really decided yet. :)
> 
> However, I think our projects do have slightly different scopes. Here's how
> I would explain it, and be sure to correct me if I am mistaken.
> 
> libconf-
>  provides a library for creating / manipulating a configuration file. It
> will know about the different formats. The user has to specify what file the
> configuration setting is in, but doesn't need to know about the internal
> format of the file.
> 
> Config4GNU-
>  tries to provide front-ends for accessing configuration settings for the
> whole system. Settings from all sorts of different files will be accessible
> through a hierarchical data model. Users who want to make a setting change
> don't need to know what file it's actually stored in or what the format of
> the file. However, Config4GNU must know about the file and what format it's
> in.


well, that would be true if libconf was alone :)
But libconf is only a layer, another layer will be built on top of it, to
abstract the location and the unicity of the information.

> 
> That said, I think there's a great opportunity for collaberation here. The
> way I see it, libconf could provide all of the parsing of and manipulation
> of configuration files for Config4GNU.

ok, why not :)
right now the templates supported are :

XF86Config
Sshd
Samba
Shell (a tons of files are supported with this template then)
Apache
Values_section (idem, this is a generic template)

I think we are moving faster than you on the first layer, maybe it would be
good that config4gnu provides the upper layer

Now we have to discuss about this layer :)

What about some irc discussion?

[Config4gnu-developer] Re: [libconf] libconf, config4gnu

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

I apologize for not responding earlier. I've been delaying because I haven't
really decided yet. :)

However, I think our projects do have slightly different scopes. Here's how
I would explain it, and be sure to correct me if I am mistaken.

libconf-
 provides a library for creating / manipulating a configuration file. It
will know about the different formats. The user has to specify what file the
configuration setting is in, but doesn't need to know about the internal
format of the file.

Config4GNU-
 tries to provide front-ends for accessing configuration settings for the
whole system. Settings from all sorts of different files will be accessible
through a hierarchical data model. Users who want to make a setting change
don't need to know what file it's actually stored in or what the format of
the file. However, Config4GNU must know about the file and what format it's
in.

That said, I think there's a great opportunity for collaberation here. The
way I see it, libconf could provide all of the parsing of and manipulation
of configuration files for Config4GNU.

For those on the libconf list that are not familiar with config4gnu, check
out http://config4gnu.sourceforge.net. Also, a mailing list has been
created, for which you can sign up at
http://lists.sourceforge.net/lists/listinfo/config4gnu-developer.

Keep in touch...
Jason Long

Re: [Config4gnu-developer] some minor changes to the gnome client

[Mark S. <ma...@sp...>]

Regarding the GladeXML object, it's a GObject... so yea, I should have
called g_object_unref on it.  The OS would free that memory at program
end, but that's rather sloppy.

Sorry about that, I'll be more careful :)

There's a couple new (small) diffs attached, with calls to
g_object_unref().


-- 
Mark A. Stratman
ma...@sp...


On Tue, 2002-10-15 at 00:43, Jason Long wrote:
> This looks great! I applied your diffs (unfortunately I had to manually
> apply the mainwin.c diff because I had made some changes to mainwin.c since
> I received your patches). The changes have been committed to CVS. If you
> want, let me know and I can give you CVS access.
> 
> Concerning your question about the naming of mainwin, I put the code that
> handles the main window in mainwin.c, as opposed to main.c, which has the
> main () function. Perhaps the properties window could be called
> propertiesdlg?
> 
> I have a question about glade_xml_new. Is the data structure that it returns
> ever need to be freed?
> 
> That's all for now. Keep it touch :)
> 
> Jason Long

Re: [Config4gnu-developer] some minor changes to the gnome client

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

This looks great! I applied your diffs (unfortunately I had to manually
apply the mainwin.c diff because I had made some changes to mainwin.c since
I received your patches). The changes have been committed to CVS. If you
want, let me know and I can give you CVS access.

Concerning your question about the naming of mainwin, I put the code that
handles the main window in mainwin.c, as opposed to main.c, which has the
main () function. Perhaps the properties window could be called
propertiesdlg?

I have a question about glade_xml_new. Is the data structure that it returns
ever need to be freed?

That's all for now. Keep it touch :)

Jason Long

[Config4gnu-developer] some minor changes to the gnome client

[Mark S. <ma...@sp...>]

I've thrown together a few minor changes for the gnome client.
The main one is the use of libglade for the interface, rather than
hard-coded C code.

If you like it, please use it :)
And if you have any suggestions, things you want changed, etc.. let me
know. One thing to note is that I stuck with the 'mainwin' naming
convention, so parts (specifically 'propertieswin') look kind of ugly.
*shrug*.

Anyhow, great project, and cheers.

(Note: the changes are also at http://sporkstorms.org/config4gnu/).
-- 
Mark A. Stratman
ma...@sp...

[Config4gnu-developer] XML representation

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

Justin, here's my current understanding of the XML representation created by
the "parsers" and read by the prototype gnome-client.

First, some definitions:
Node:
 a configuration "Node" is an element of the configuration. it has a name,
type, a list of child nodes, and a list of associated properties. In the
gnome-cfg prototype, nodes appear in a tree on the left pane.

Property:
 a configuration "Property" is an association between a name and a value. In
the prototype, properties appear in the right pane when a node is selected.

XML representation

there is a rough correspondance between XML entities and configuration
nodes. Basically, any entity with an attribute "sectionname" defined will
appear as a node.

the type of node is defined by the name of the element.

For instance, the entity
 <section sectionname="Daemons"> ... </section>
defines a node of type "section" named "Daemons".

Properties are defined by <property> elements.
The name of the property is the "name" attribute of the property element.
The value of the property is the contents of the <value> entity which the
<property> element contains.

As an example, this XML excerpt:
 <property name="debug level">
   <value>10</value>
 </property>
defines a property with the name "debug level" and the value "10".

This XML representation is what I've been working towards in the prototype.
Let me know what you think.

Jason

[Config4gnu-developer] News: status update

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

Config4GNU, a project to provide a single unified interface to system
configuration data on Linux computer systems, is currently analyzing
existing configuration file formats in order to best design a data model
that can represent all of the various types of configuration. Work is
currently focused on creating a systems requirements specification document
and a document analyzing the various configuration file formats found on
Linux.

Two weeks ago an article outlining the project vision of Config4GNU was
published on http://freshmeat.net, and has received quite a bit of feedback.
The article can be viewed at http://freshmeat.net/articles/view/565/. The
feedback was mostly positive. The few negative comments either stated that
the project was redundant or unnecessary, or came from a misunderstanding of
what the project was about. We try to address some of the misunderstandings
using the Freshmeat comment system. We will add some of the more frequently
misunderstood aspects to the FAQ section of the website
(http://config4gnu.sourceforge.net).

A mailing list has been created for Config4GNU development. Please subscribe
at http://lists.sourceforge.net/lists/listinfo/config4gnu-developer if you
are interested in actively participating in Config4GNU development.

Config4GNU has also recently become aware of another project that has just
started and has similar goals. The project is called libconf, and
information about it can be found at
http://www2.damz.net/theme1/libconf.html. One of the major goals we have is
not to unnecessarily duplicate effort, and this is one area where we may be
able to benefit each other's projects.

[Config4gnu-developer] Welcome to config4gnu-developer

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

Welcome to the config4gnu-developer mailing list. This message is to serve
as a welcome for people browsing the archives as well as to test that the
list is working :)

Config4GNU is a project to develop a unified configuration interface system
for Linux and Linux-compatible computer systems. It will work by reading the
existing configuration files and creating a model of the configuration so
that all sorts of different configuration file formats can be accessed using
the same methods and notation. Changes made to the model will be made to the
underlying configuration files seemlessly. Changes made to the underlying
configuration files will be reflected in the model.

For more information, see our web page at http://config4gnu.sourceforge.net

Jason Long