config4gnu-developer — Config4GNU developers list

[Config4gnu-developer] forms and class definition files

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

Config4GNU developers,

I've been at work trying to get the "forms" implemented. I had been working
on "wizards" but decided that "forms" should probably come first... I think
they're less complicated.

Forms are listed by node type. E.g. there might be a node type called "user"
and when that node type is selected in the front-end the program can display
a form for entering "user" properties.

But in order to get the forms available, we need to know where to specify
them. In other words, given a particular node, how can I know what forms to
display. ... If I select a node named "public" of type "section" within a
node of type "inifile", I want to see a form for editing properties of a
Samba share. But how is Config4GNU going to know that this is a Samba share?

Somehow we need a way to map those "section" nodes in the inifile to nodes
of type "sambashare" or similar. Once the nodes are of type "sambashare" it
is a simple matter to associate the forms for Samba shares with those nodes.

Here are a few approaches I've thought of to this problem:

1. Make the parsers smarter, or make additional parsers specific to the
applications. This seems to contradict our idea to make generic, flexible
parsers.

2. Specify some sort of transformation between the output of the parsers and
importation into the configuration tree. A language such as XSLT is powerful
enough but then we need to specify a transformation for both ways (i.e. the
data has to go back to the parser in the original form).

3. This third idea I came up with specific to Samba but it may work for the
general case. Have the <samba> class specify what child nodes to use, and
have Config4GNU match them based on requirements. E.g. the <samba> class
specifies that possible children are <sambaglobal>, <sambahomes>,
<sambaprinters>, <sambaprintershare>, <sambafileshare>. Then, the class
files for each of these child nodes specify requirements...
  e.g. <sambaglobal> specifies that the name of the section must be "global"
       <sambahomes> specifies that the name of the section must be "homes"
       <sambaprintershare> specifis that the property named "printable" (or
synonyms) must have the value "yes" (or synonyms).

What do you think? I think approach 3 is preferable because it seems like it
is the simplest. I don't think we want third-parties to have to write their
own parsers or write complicated XSLT stylesheets. (Although they can always
use the generic class for their fileformat, e.g. inifile.)

If you agree that option 3 is best, what kind of syntax should be used to
express these requirements? While we're at it, what syntax can be used to
express property defaults, descriptions, and data types?

Here's a sketch...

<class name="sambafileshare">
  <extends class="inisection"/>
  <required-property>
    <name>path</name>
  </required-property>
  <property-definition>
    <name>path</name>
    <datatype>path</datatype>
    <description>....</description>
  </property-definition>
  <property-definition>
    <name>writeable</name>
    <datatype>boolean</datatype>
    <description>...</description>
    <default-value>no</default-value>
  </property-definition>
</class>

Jason Long

[Config4gnu-developer] libconfig4gnu reference documentation

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

I have been asked to provide some documentation for the libconfig4gnu source
files so that people other than me can contribute to this part of the
project. I am starting to comply...

I'm using the gtk-doc program to document the API. The appropriate files are
in config4gnu/doc/reference. gtk-doc must be installed (on Gentoo, you can
emerge gtk-doc). If gtk-doc is not installed, ./configure detects this and
skips that part of the build (I hope). Generated files are put in the html
subdirectory.

Basically, gtk-doc parses through the C code and reads comments to document
the code. Section introductions are done using the files in reference/tmpl.
The documentation is far from complete, but for now if anyone wants to try
building the documentation he can. Report if you have any problems.

Jason

Re: [Config4gnu-developer] flatfile not being written

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

Actually, the changes I committed to CVS last night broke the "writecommand"
ability.

Here's a summary of the changes I made and my reasoning:

The name of the element defines the "type" of the node. The type of the node
defines what parser to run. When libconfig4gnu encounters a node type it
hasn't seen before it tries to dynamically load information about that type
from the classes directory.

For instance, when the node type of "inifile" is encountered, libconfig4gnu
reads the config4gnu/data/classes/inifile.xml file and finds out that it
needs to run parse.ini.pl to read configuration and unparse.ini.pl to write
configuration.

The reasoning for this is when a third party adds a new parser, they can add
the parser to the parsers directory and add a "class definition file" to the
classes directory. Then the user will be able to create a node of this new
type from the UI, specifying the node type and location of the configuration
file.

Next we'll be able to create class definition files for specific
applications. For instance, a class definition file for "groups" would
extend the colonfile class, and define that the config file is /etc/group
and it would define names, descriptions, and possibly default values for the
different parameters.

I still need to do the "writecommand" functionality.

Jason Long

Re: [Config4gnu-developer] Re: libconf status

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

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

> On Mon, 2002-10-28 at 04:01, dams wrote:
> 
> > There is a cvs repository here:
> > 
> > http://cvsweb.tuxfamily.org/cvs/src/?cvsroot=ugtk
> > 
> > The files to get are:
> > libconf.pm  <- the lib
> > test_conf.pl  <- test program
> > templates <- the direcory containing the templates.
> > 
> > This cvs is too slow, so it will be moved somewhere else, either on sf.net or
> > on gentoo.org
> 
> This CVS seems to be only web-based.  Is that the case?  It would be
> much easier to access it via normal CVS.  Also, can we have write access
> to it, or do you prefer we send you diffs?

it's not only web based :

CVS access is available by two medium: pserver or ssh.
You must create a depencies between the repository and a group (see group
management).

People could access to CVS repository anonymously with PSERVER:
Access: export CVSROOT=:pserver:ano...@cv...:/cvsroot/ugtk 

I prefere not to give you write access, because handling this without security
problem is difficult at the moment, that's why I'm planing to change the cvs
server.

So I'm sorry, but you will have to send me the diffs so that I include it :/

> 
> > > 
> > > Jason wrote a basic converter to XML and I was wondering if you would
> > > prefer this so that the perl structures can still be used by libconf, or
> > > if you would accept changes that made libconf natively output XML.
> > 
> > It depends how it's done. xml converter seems fine for now.
> 
> OK, we'll do the XML converter for now.  I guess it shouldn't be too
> much slower anyway.

nice, thanx !

Can you describe how you plan to do it? Maybe I can advise you on some stuffs

[...]

> > 
> > I think LGPL is not that good, because it allows people to use your work
> > without give back to you or the community. The fact that the GPL is viral is
> > something I actually like :)
> 
> What are the implications of libconf being GPL while CFG is LGPL?  Does
> a program using CFG then also use libconf, requiring it to be GPL, or
> does going through CFG allow it to be non-GPL?  

if CFG uses libconf, it has to be GPL afaik. CFG itself has to be GPL. I'm
sorry about that, but that actually the purpose of the GPL

Re: [Config4gnu-developer] Re: libconf status

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

On Mon, 2002-10-28 at 04:01, dams wrote:

> There is a cvs repository here:
> 
> http://cvsweb.tuxfamily.org/cvs/src/?cvsroot=ugtk
> 
> The files to get are:
> libconf.pm  <- the lib
> test_conf.pl  <- test program
> templates <- the direcory containing the templates.
> 
> This cvs is too slow, so it will be moved somewhere else, either on sf.net or
> on gentoo.org

This CVS seems to be only web-based.  Is that the case?  It would be
much easier to access it via normal CVS.  Also, can we have write access
to it, or do you prefer we send you diffs?

> > 
> > Jason wrote a basic converter to XML and I was wondering if you would
> > prefer this so that the perl structures can still be used by libconf, or
> > if you would accept changes that made libconf natively output XML.
> 
> It depends how it's done. xml converter seems fine for now.

OK, we'll do the XML converter for now.  I guess it shouldn't be too
much slower anyway.

> > I also just noticed that libconf is released under the GPL.  Is there
> > any particular reason why you chose that over the LGPL, or do you have
> > anything against using the LGPL?  We had chosen the LGPL so that other
> > software (commercial or otherwise) could use CFG, but I don't pretend to
> > fully understand the whole licensing mess.  My basic understanding is
> > that the LGPL is less restrictive but maybe you have some insight from
> > working w/ Mandrake.
> 
> I think LGPL is not that good, because it allows people to use your work
> without give back to you or the community. The fact that the GPL is viral is
> something I actually like :)

What are the implications of libconf being GPL while CFG is LGPL?  Does
a program using CFG then also use libconf, requiring it to be GPL, or
does going through CFG allow it to be non-GPL?  

Justin

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

Re: [Config4gnu-developer] resolv.conf parser

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

On Mon, 2002-10-28 at 02:52, Gregory Richard Troisi Stoll wrote:
> I wrote a quick parser for files of the style of resolv.conf.  Attached
> are the parser and unparser, and the new config4gnu.xml (and
> resolvfile.xml).  Let me know if it looks ok, and if there's something
> more productive I could be doing :-)

Thanks again for the files!  This will be useful for our prototypes. 
I'll check them out & put them in CVS later today & let you know if I
run into any trouble, but briefly looking at them, they look good.

As far as productive things you can be doing, we're looking at migrating
to libconf for our parsing.  You can get libconf by checking it out of
CVS at the place where dams mentioned in an email to this list sent this
morning titled "Re: libconf status".  We've currently got a few minor
changes to it we've made and written a very basic translator to make it
output XML.  While your parsers will likely be used for the time being,
we will probably be moving toward migrating them to libconf.  

If you are interested in working on the parsers, I would suggest
contributing to this area either by translating your parsers to
libconf's way of doing things, improving the translator, and maybe a
little bit of helping develop libconf.  Probably the highest priority on
our list right now is improving the translator (since it can only
translate in 1 direction right now).

We don't have write access to the libconf CVS at the moment, and I know
Jason has done work that I wouldn't want you to duplicate...  I'm hoping
he reads & responds to this email & checks his translator into our CVS
so that you can work on it if you want.

Anyway, I say that would be a great way to contribute since libconf is
in perl and you seem good at it.  If you'd rather do something directly
for a main part CFG, let us know & we can try to give you something
there instead or in addition.

Finally, I've added you as a CFG developer on sf.net, so you should have
CVS access to do future checkins of things.  Again, I will checkin your
changes later today, so they won't show up immediately (unless you want
to do it yourself).

Justin

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

Re: [Config4gnu-developer] flatfile not being written

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

On Mon, 2002-10-28 at 00:28, Gregory Richard Troisi Stoll wrote:
> I updated the flatfile parser/unparser to just have properties with name
> "module" (and so comments are not shown as well), so it looks much nicer.
> I have two questions.
> 
> 1) Now when I modify the properties and select "activate", the file is not
> written out to /etc/modules (and I'm running as root).  Did I somehow
> break this in the new parser/unparser, and if so, any suggestions of how
> to fix it?

Find your config4gnu.xml and look for the section for Boot Modules. 
Should be towards the end.  The writecommand tells CFG what to do to
write the file.  To help prevent CFG from really messing with your
system, it currently doesn't write ANY changes to /etc.  Instead, the
writecommands tell it to write to /tmp, so chances are your updated file
is in /tmp/modules.new.  If not, then I will have to look into it more. 
BTW, I would suggest *not* running CFG as root at this point, just in
case someone accidentally tells it to really overwrite your /etc files.

> 2) Presumably, since the flatfile format is used in a number of different
> places, we should either use a generic name for properties (like "item" or
> something), or we should have a mechanism for passing in specific names
> (like "module") to the parser and unparser.  I think passing in specific
> names would be a bit user-friendlier, since then it is clear what the user
> is viewing and changing.  Is there currently a way to do this?

Well, yeah, there is a problem with the names of things.  We want to
keep the XML tags to a minimum, so making a new tag is probably not the
way to go.  We have been kicking around the idea of taking the
name="blah" out of the <property> tag itself and instead making a <name>
tag under the <property> tag.  Then, we would add a <displayname> tag
under <property> which contains the name that the UI should display it
as (which may be Module, Alias, etc. OR a translation of the <name> into
the user's native language).  If you want to make your parser do this,
and use <displayname> to add this information, that would be fine.  I
would suggest then just leaving <name> empty (but still including it).

Justin


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

Re: [Config4gnu-developer] XML specification (1st draft)

[Peter W. <wie...@we...>]

Hi!

Justin wrote:
>[...]
> should be.  Once it is stabilized, we'll publish a 1.0 XML spec and
> detail which is necessary to be compliant w/ the spec.  If you have
> any suggestions, or are working on any other type of specifications
> for these sorts of things, we'd love to compare notes.  If you want
> to help us define the exact spec, we'd be open to that as well.
>
What I'm thinking of is a separation between the syntax and the
semantics =3D the naming order.
If you convert to/from linuxconf, there alerady is a point of
cross-software order. And you should document and develop
syntax and semantics separated from each other (if you're not
already donig so), at lest IMHO.

> I've looked over your website and I noticed you mentioned a few
> things about CFG [...]
> [...].  I'll try to clear up some things, not that I think
> you're totally off-base, but I suspect there may be places we are
> unclear:
>
> Your mention that we want to be an abstract UI is 100% correct, we
Yes CFG is an UI between sys administrator and the distro specific
scripts and tools.
But when I write about abstract UI what "spooks" through my mind is an
abstract UI ***for*** CFG and linuxconf and ...
Because my confcoord project just started, the documentation files
"explode" (the become biger and more very fast). Later this speed
will drop.
I will soon present my software "AUI". It sucks a bit :) but it shows
my ideas. The console implementation already works, now comes the xlib
implem.

> As far as our XML format, no one using the final product of our
> project should need to understand XML at all.  Programmers using it
> will need to understand how to retrieve data from XML, which is
> very easy in most languages.  Using the XML won't be required, as
> the native config files are still the authoritative version, so
> things won't *need* to be re-written to allow CFG to configure
> them.
I extended the comment "complicated" about XML because I think
there are some sort of XML parsing libs or so.
In the chapter "conf languages" I think of programmers who write
the equivalent of your main engine and/or conf data scripts (but for
the middle layer and for many sys conf areas).

> structures.  Right now we use our own basic parsers, and part of
> the process of adopting libconf would be getting their parsers to
> understand XML and/or writing a translator between their perl
> structures and XML (which we've done to an extent).
That is exactly the sort of project I would like to see.
I'll try for example to write documentations that could help.

> If you are interested in helping out with or joining our project,
> we would welcome any contributions you have.[...]
What I've seen so far CFG has the best (the only!) design for conf
standardization.
But there are still a lot of parallel/isolated developments in other
projects, that keep me busy!
Currently I think it's better to just stay on your mailing list and
suggest ideas and tell if in rare occasions I manage to produce
some ugly code.

> [...]  If you want to
> maintain your own project, we are interested in there being a
> configuration standard and would be interested in helping to define
> it.
Yupp! I care about such a standard very much, too.
This will take some time (You already guessed that I bet).
But to overcome the extrem fragementation of linux conf software,
I it is an advantage to take it slow and think in long time terms.
Currently I plan helping for such a standard for the naming order
( =3D naming system =3D semantics =3D ontology).
1.) I first want to document existing ones.
2.) Then I want to look if I can sys conf tool projects that want to
support a semantics standard.
3.) In my plan (plans don't always work) my work ends here, because
several people who have lots of experience in designing linux conf
semantics (maybe from linuxconf?) will sit together and create a
linux conf semantics standard project.
There are other things for conf standardization I will work on, of
course.

> Thanks for your interest in our project & sorry it took til now to
> respond.
To me it looked very fast. Please expect much slower responses and
actions from me!

Kind regards
Peter Wiehe

[Config4gnu-developer] Re: libconf status

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

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

> Dams,
> 
> I've got some questions about your libconf layer.  We've made some basic
> modifications and Jason has written a basic translator to convert the
> perl structure to XML (but not the other way around).  I downloaded your
> tarball dated the Oct 25th and it seems to have some diff-like lines in
> the perl.  I was wondering if you could provide a current version of
> libconf, if it has been modified in the last week or so.

There is a cvs repository here:

http://cvsweb.tuxfamily.org/cvs/src/?cvsroot=ugtk

The files to get are:
libconf.pm  <- the lib
test_conf.pl  <- test program
templates <- the direcory containing the templates.

This cvs is too slow, so it will be moved somewhere else, either on sf.net or
on gentoo.org

> 
> Jason wrote a basic converter to XML and I was wondering if you would
> prefer this so that the perl structures can still be used by libconf, or
> if you would accept changes that made libconf natively output XML.

It depends how it's done. xml converter seems fine for now.

>  I'm
> not sure what difference one or the other makes in the end, but its a
> question nonetheless.  We won't spend too much time writing fancy
> translators if you'll soon be going to XML, we'll just do what we need
> to use its basic features.
> 
> A question related to this would then be do you have libconf in CVS
> someplace so that we could check in any changes we make to it?  If you
> don't have it in CVS right now, we can add it to our repository on
> SF.net if you like.  We'd like to help you work on it if thats alright
> with you, since it seems your basic design of libconf works well.

see above

> I also just noticed that libconf is released under the GPL.  Is there
> any particular reason why you chose that over the LGPL, or do you have
> anything against using the LGPL?  We had chosen the LGPL so that other
> software (commercial or otherwise) could use CFG, but I don't pretend to
> fully understand the whole licensing mess.  My basic understanding is
> that the LGPL is less restrictive but maybe you have some insight from
> working w/ Mandrake.

I think LGPL is not that good, because it allows people to use your work
without give back to you or the community. The fact that the GPL is viral is
something I actually like :)

[Config4gnu-developer] resolv.conf parser

[Gregory R. T. S. <gs...@ri...>]

I wrote a quick parser for files of the style of resolv.conf.  Attached
are the parser and unparser, and the new config4gnu.xml (and
resolvfile.xml).  Let me know if it looks ok, and if there's something
more productive I could be doing :-)

-Greg

--
Gregory Stoll
gs...@ri...
"The story you are about to see is a fib, but it's short"
- Mathnet, "Square One"

[Config4gnu-developer] flatfile not being written

[Gregory R. T. S. <gs...@ri...>]

I updated the flatfile parser/unparser to just have properties with name
"module" (and so comments are not shown as well), so it looks much nicer.
I have two questions.

1) Now when I modify the properties and select "activate", the file is not
written out to /etc/modules (and I'm running as root).  Did I somehow
break this in the new parser/unparser, and if so, any suggestions of how
to fix it?

2) Presumably, since the flatfile format is used in a number of different
places, we should either use a generic name for properties (like "item" or
something), or we should have a mechanism for passing in specific names
(like "module") to the parser and unparser.  I think passing in specific
names would be a bit user-friendlier, since then it is clear what the user
is viewing and changing.  Is there currently a way to do this?

I'd be happy to send in my new files, but I wanted to get #1 cleared up at
least before I do so...

-Greg

--
Gregory Stoll
gs...@ri...
"The story you are about to see is a fib, but it's short"
- Mathnet, "Square One"

[Config4gnu-developer] libconf status

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

Dams,

I've got some questions about your libconf layer.  We've made some basic
modifications and Jason has written a basic translator to convert the
perl structure to XML (but not the other way around).  I downloaded your
tarball dated the Oct 25th and it seems to have some diff-like lines in
the perl.  I was wondering if you could provide a current version of
libconf, if it has been modified in the last week or so.

Jason wrote a basic converter to XML and I was wondering if you would
prefer this so that the perl structures can still be used by libconf, or
if you would accept changes that made libconf natively output XML.  I'm
not sure what difference one or the other makes in the end, but its a
question nonetheless.  We won't spend too much time writing fancy
translators if you'll soon be going to XML, we'll just do what we need
to use its basic features.

A question related to this would then be do you have libconf in CVS
someplace so that we could check in any changes we make to it?  If you
don't have it in CVS right now, we can add it to our repository on
SF.net if you like.  We'd like to help you work on it if thats alright
with you, since it seems your basic design of libconf works well.

I also just noticed that libconf is released under the GPL.  Is there
any particular reason why you chose that over the LGPL, or do you have
anything against using the LGPL?  We had chosen the LGPL so that other
software (commercial or otherwise) could use CFG, but I don't pretend to
fully understand the whole licensing mess.  My basic understanding is
that the LGPL is less restrictive but maybe you have some insight from
working w/ Mandrake.

Thanks,

Justin

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

Re: [Config4gnu-developer] XML specification (1st draft)

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

On Sun, 2002-10-27 at 05:27, Peter Wiehe wrote:
> In my opinion, for the stated C4G goals you must listing the nodes and
> properties in plain text as an explaining docu for humans (and in XML,
> too, of course). So that you and other conf tool developers can
> 	- discuss about a common naming system.
> 	- use different naming systems with the C4G main C engine.
> (Sooner or later you will have to publish the data XMLs in versions,
> where new versions will sometimes have slight differences in the
> naming system.)

Yes, we will be doing that in the near future.  Right now, our format is
changing very often, so we it isn't as specific as it should be.  Once
it is stabilized, we'll publish a 1.0 XML spec and detail which is
necessary to be compliant w/ the spec.  If you have any suggestions, or
are working on any other type of specifications for these sorts of
things, we'd love to compare notes.  If you want to help us define the
exact spec, we'd be open to that as well.
 
> Is there already some sort of general XML browser/displayer? It would
> be not only useful for sys conf tools, but for nearly all XML
> stuff. So I guess there must be such a thing. It could be utilized for
> the UI.

Sadly, not really.  There are some clunky ones that aren't near specific
enough to do this type of thing.  Fortunately, it is very easy to write
a program that understands XML.  In fact, at this point we've got a gtk
version that can modify config files and a PHP interface that can browse
the XML tree structure.  We think this is necessary anyway because there
are some widgets & other things that are specific to configuration that
the UIs will need.

You can checkout the gtk version from CVS and try to build/run it,
although at this point you may run into some trouble, but we'd be happy
to help resolve them.  You can also look at the screenshots on our
website to see the gtk interface.  

A PHP demo is available at http://cs.messiah.edu/~cfg/ and reads the
various dummy config files (mostly just smb.conf php.ini passwd and
group at the moment).  The PHP client doesn't show comments or anything
else, only the values of the different configuration directives.

> Did I understand it right that the INI file example would belong to
> the backend? Because I think in the middle layer should be only one
> format, the C4G format. Justin mentions the same if I understand him
> right.

Yes, thats correct.  Think of it as the United Nations.  There are
however many different people, each speaking who knows what language. 
Some want information, some have information, others (the moderator of a
UN meeting whatever he's called) help keep things orderly without having
to know every language being spoken (perhaps he knows only french, the
standard diplomatic language)  

With CFG, the middle layer (the main library) is the moderator, and it
speaks *ONLY* CFG XML.  The parser/unparsers do the translation when the
middle layer wants to read/write the config files, converting to and
from between XML and the native format.  The front ends must understand
CFG XML (at this point anyway, or handle their own conversion to
something else) and use the middle layer as a go-between to the actual
config files.  This way, there is a single standard language to worry
about, and if you can speak it, then you're set.  Politicians are smart
after all...

> Could the properties that Justin suggested be divided into optional
> and neccessary? So that on some systems the optional ones can be
> ignored (and C4G development can start without them and later add
> them)?

Yes, most of them are optional.  Again, at this point it isn't entirely
clear, but for the parsers to work properly, they assume that any
parameter has a name specified and a <value> tag in them.  The rest
*should* be optional, and maybe value should be too, but I can't
guarantee our prototypes will work w/o them.  A 1.0 version should be
able to.


I've looked over your website and I noticed you mentioned a few things
about CFG (our "official" abbreviation is now CFG not C4F, we decided
CFG is easier to type and less confusing) that you mentioned.  I'll try
to clear up some things, not that I think you're totally off-base, but I
suspect there may be places we are unclear:

Your mention that we want to be an abstract UI is 100% correct, we want
to be a uniform way to access configuration (by users, the things being
configured themselves, scripts, etc.) through various methods.  The
backends I think are better described as "config file format specific
translators", since really thats *all* they do (maybe some basic
validation of that specific file format too).

As far as our XML format, no one using the final product of our project
should need to understand XML at all.  Programmers using it will need to
understand how to retrieve data from XML, which is very easy in most
languages.  Using the XML won't be required, as the native config files
are still the authoritative version, so things won't *need* to be
re-written to allow CFG to configure them.


Finally, we're looking at using libconf for our backend layer, which
itself it also a recently started project.  It currently handles basic
translation to & from config files and perl structures.  Right now we
use our own basic parsers, and part of the process of adopting libconf
would be getting their parsers to understand XML and/or writing a
translator between their perl structures and XML (which we've done to an
extent).

If you are interested in helping out with or joining our project, we
would welcome any contributions you have.  If you want to maintain your
own project, we are interested in there being a configuration standard
and would be interested in helping to define it.

Thanks for your interest in our project & sorry it took til now to
respond.

Justin


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

[Config4gnu-developer] XML specification (1st draft)

[Peter W. <wie...@we...>]

Hi!
AS I already said I'm trying to write docu about C4G and other
software and contribute some code for an abstract UI.

Your draft may help to cooperate with other conf software.

Thanks for adding HTML, because I'm not used to DocBook.

In my opinion, for the stated C4G goals you must listing the nodes and
properties in plain text as an explaining docu for humans (and in XML,
too, of course). So that you and other conf tool developers can
=09- discuss about a common naming system.
=09- use different naming systems with the C4G main C engine.
(Sooner or later you will have to publish the data XMLs in versions,
where new versions will sometimes have slight differences in the
naming system.)

Is there already some sort of general XML browser/displayer? It would
be not only useful for sys conf tools, but for nearly all XML
stuff. So I guess there must be such a thing. It could be utilized for
the UI.

Did I understand it right that the INI file example would belong to
the backend? Because I think in the middle layer should be only one
format, the C4G format. Justin mentions the same if I understand him
right.

Could the properties that Justin suggested be divided into optional
and neccessary? So that on some systems the optional ones can be
ignored (and C4G development can start without them and later add
them)?

Kind regards
Peter Wiehe

[Config4gnu-developer] wizard screenshot

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

For wizards I had in mind using a generic description file to generate the
dialog boxes. This generic file would allow us to create one file for all
interfaces (Gtk, HTML, command-line).

To investigate how easy this would be I created a simple prototype. The
prototype files are in CVS under src/clients/gnome-client, but running them
requires certain external files to be in certain places. (sorry).

I created a screenshot and posted it on the website. The screenshot shows an
entry form for XFree86 mouse configuration. The controls in the screenshot
are "bound" to certain properties, as specified in the wizard definition
file. This causes the controls to  show the current settings. Ideally, when
the user changes the value of the control, the program will update the
XF86Config file.

For now, check out the screen that at
http://config4gnu.sourceforge.net/screenshots/, and the files in CVS. Again,
it's not meant to be pretty.

Jason

[Config4gnu-developer] Re: XML specification (1st draft)

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

On Sat, 2002-10-26 at 13:54, Jason Long wrote:
> Justin
> 
> Attached is an attempt to clearly document the XML that is used to
> communicate between the parsers and the Config4GNU system. It is not even
> close to being set in stone; I already have things I want to change about it
> :). But I send it for your information and feedback.
> 
> It has a few diagrams with it so I attach it as a tarball. It is in Docbook
> format, but I included the HTML as well.

As requested, some feedback (in the order things appear in the file). 
If you want, I can update these things in the sgml (or just the ones you
agree with), or whatever.  Once I get your response, I can add it to the
website source tree & make it live (unless you want to?).

Your hierarchy in Figure 1 shows "localhost" as the top node in the xml
structure.  At this point, that is no problem, but what about if/when
remote administration is possible?  I submit that we should have a node
at least 1 (or even 2 to allow for hosts to be grouped?) levels above
localhost to allow room for this.  Granted, I'm not sure whether that
would even matter since our solutions seem pretty general, but we should
at least allow room in the code/spec for these levels to be added
later.  Appears from the source tree you're doing this to some extent.

In Example 2:  I'm unsure of your reasoning for the <inifile> and
<inisection> tags.  I suggest that inisection should be generalized to
section so frontends don't need to worry about whether something is
section, inisection, apachesection, colonsection, etc.  I'm looking
through the source tree, perhaps this is handled more easily than I'm
thinking it can be...  I'm still wondering whether or not this is an
unnecessary distinction.  I do agree w/ your use of <inifile> and
similar though, I assume in your config4gnu.xml you're over-riding the
read & write command default values for testing purposes, very nice.

Regarding sub-tags of Properties:

They should have the 3 you mentioned, whitespace, comment, value.  They
should also have rightcomment (if we're still allowing those). 
Whitespace *must* be inside a CDATA (since otherwise "whitespace" is
ignored by most/all xml parsers, making the tag useless)  Comments, I
suggest, also should always be in CDATAs for uniformity as for
multi-line comments, the linebreaks would be lost upon unparsing. 
Values should also be in CDATAs all the time for the same reasons,
although I admit I can't think of a situation off hand where a value has
whitespace in it, but I'm sure they do somewhere.

I can't think of a situation where multiple whitespace or comment tags
are needed, so I think only allowing 1 is safe.

Some additional properties I believe may be important to leave room for
at this point.  Some of these are just ideas, I'm not sure how I feel
about them:

- <default>, the default value of a node.  This need not be specified on
*each* property since it could be inherited, but in most cases it would
be specified.  This might be difficult to handle, but its important. 
Widgets could then display the default value in a greyed out text,
indicating that the value isn't explicitly set, but only set by
default.  Such a <property> could have a <default> sub-node but not a
<value> sub-node, and still make sense.  Either the unparser or the
middle layer would be responsible for ignoring <property> tags w/o an
explicitly set value, so that this doesn't break things.

- <doc>, distro/vendor/etc supplied documentation on the property (this
should also exist for other node types!).  It should be in HTML format,
since both a web-based client and a GUI can easily display HTML.  For
other formats, it can be converted to plain text, if it is displayed.

- <man>, any relevant information from a manual page.  This data would
ideally be automatically collected by a man page parser (Samba has a
great manpage for smb.conf that would allow this).

- <type>, the type of the property (to tell which widget/validation for
the front end to use), be it IP, Text, Integer, Color, etc. or maybe
even a special type such as User which would lookup data from another
section of the XML to create an appropriate widget.

- <required> 0 or 1, whether it must be set to a non-empty value

- <excludedby> would contain subnode(s) indicating which other
parameters (or values of parameters) preclude this parameter having any
usefulness or being allowed to be set.  An example (from samba of
course) is that if load printers is set to no/false, then setting the
value of the printing parameter is silly.  This would allow front ends
to say either "Sorry, you can't set this property because property XXX
is set to AAA", or "In order for this property to be meaningful, you
must set property XXX to AAA, shall I do this for you?"  Maybe this
would make more sense being separated into <excludedby> and <needs> to
break it into the two slightly different types of conditions.

- <permissions> This might make more sense to apply to sections, not
parameters, although both would probably be better.  This tag won't be
used any time in the conceivable future.

- <name> This could be used to replace the current <property
name="blah"> convention.  Instead the name="blah" would specify that the
node is to be *displayed* as blah, whereas its real name in the config
file would be in the <name> tag.  I'm thinking this would be good for
things like the /etc/modules.conf where each node is (or may) be the
same thing in the config file, but they should be displayed
differently.  I'm not sure if that makes sense.

- <displayname> This is similar to <name>, and mostly just a slightly
different idea.  Instead of the name="blah" inside the actual <property>
tag, just get rid of it altogether and have a name tag be the real name
in the config file and displayname be the name it is displayed to be in
the tree and/or in the list of properties.  This could (there are other
ways to do it) help allow for internationalization.  

A lot of these tags would *not* be created by the config file parsers. 
Some, such as required, needs, excludes, & default could be added by the
middle layer based on meta-config files.  Things like <man> tags would
be included by merging the output of parse.ini.pl /etc/samba/smb.conf
with the output of parse.man.pl smb.conf

I suggest that just as the middle layer would be responsible for merging
in the docs & default values as the XML travels from the back to the
front ends, it would also be responsible for merging out anything which
the unparser isn't supposed to know about or would make the unparsing
process needlessly complicated.  The unparsers should have to worry
about as little as possible, since they may be written in a slower
language and plus this makes them easier to write and less prone to
errors in the way they handle those things.

Just some thoughts.

Justin

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

[Config4gnu-developer] XML specification (1st draft)

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

Justin

Attached is an attempt to clearly document the XML that is used to
communicate between the parsers and the Config4GNU system. It is not even
close to being set in stone; I already have things I want to change about it
:). But I send it for your information and feedback.

It has a few diagrams with it so I attach it as a tarball. The specification
is in Docbook format, but I included the HTML as well. The diagrams were
created in Dia. If Dia is installed you should be able to `make' to create
the graphics.

Jason

[Config4gnu-developer] I'm working in a similar direction

[Peter W. <wie...@we...>]

Hi, C4G developers!

I just created my confcoord project at sourceforge.
Shortly, it is about similar issues like C4G.
My approach is not so much coding, but observing what is out there and
how we can
1.) reduce parallel developments, at least a little bit
and
2.) interchange between conf tools

First I attempt to do the following:
Writing my own abstract UI. Very very simple, so that talented coders=20
can develop further.into this direction.
Investigate if libyui is a useful abstract UI.
Write a description of existing conf tools (maybe: conf language,=20
supported conf areas, development status/maturity, which OS/distro=20
etc.)
Write some parsers (or utilize existing parsing libs) if useful. So=20
everyone can have his own favorite conf tool, but nonetheless we can=20
share conf data (including conf logic rules). This is a little bit=20
sweat, of course...
Apply to window managers, browsers, bootloaders and the linux-kernel's
make-process.
Maybe: Investigate several languages for system conf, existing ones=20
and general/new ones. Maybe XML, Guile, ((Prolog)).

But I can't give a time schedule. Sometimes I may be fast, sometimes=20
slow.

Kind regards
Peter Wiehe

Re: [Config4gnu-developer] real "flatfile" parser/unparser

[Gregory R. T. S. <gs...@ri...>]

> Greg-
>
> The files have been committed. Here is some feedback :)

Thanks!  I appreciate the feedback.

> 1. The following:
>      else {
>           die $line;
>      }
>    has to go. If a line does not match one of the patterns it should somehow
> be preserved in the XML file. Otherwise, when the file is rewritten, that
> data (valid or not) is lost. Perhaps you could use a comment tag, since you
> preserve the '#' in comments.

Agreed.  Perhaps we could put it in a comment and add a comment on the
line before indicating that the parser didn't know what to do with this
line?

> 2. Can we put all the parameters into one big section? Since all the data in
> a "flatfile" is for one purpose, I think it makes sense to group it
> together. Instead of incrementing section numbers we could increment
> parameter numbers. Or the parameters could all have the same name, since
> they all are used the same way.

Yeah, that makes more sense, but I wasn't sure if the core layer had
support for this.  Having the parameters all have the same name makes the
most sense to me.

> 4. This hasn't been done for the other parsers, but I think it'd be nice to
> have an area at the top of each parser to explain the file format that it
> works with. Something like
>
>   Handles files that contain one or more values. Each value exists on a line
> by itself. Blank lines and lines beginning with '#' are ignored by the
> application.

This is a good idea, and I'd be happy to do it.  Should I continue to
email patches to the list or should I commit them in CVS?

> Thanks for contributing and I hope to hear more from you!

Thanks!

> Jason Long

-Greg

--
Gregory Stoll
gs...@ri...
"The story you are about to see is a fib, but it's short"
- Mathnet, "Square One"

Re: [Config4gnu-developer] real "flatfile" parser/unparser

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

Greg-

The files have been committed. Here is some feedback :)

1. The following:
     else {
          die $line;
     }
   has to go. If a line does not match one of the patterns it should somehow
be preserved in the XML file. Otherwise, when the file is rewritten, that
data (valid or not) is lost. Perhaps you could use a comment tag, since you
preserve the '#' in comments.

2. Can we put all the parameters into one big section? Since all the data in
a "flatfile" is for one purpose, I think it makes sense to group it
together. Instead of incrementing section numbers we could increment
parameter numbers. Or the parameters could all have the same name, since
they all are used the same way.

3. I already made a slight change to the "unparser" to allow this. Instead
of

  $param = $section->getElementsByTagName('parameter')->item(0)

it is changed to

  foreach my $param ($section->getElementsByTagName('parameter'))

4. This hasn't been done for the other parsers, but I think it'd be nice to
have an area at the top of each parser to explain the file format that it
works with. Something like

  Handles files that contain one or more values. Each value exists on a line
by itself. Blank lines and lines beginning with '#' are ignored by the
application.

Thanks for contributing and I hope to hear more from you!

Jason Long

[Config4gnu-developer] real "flatfile" parser/unparser

[Gregory R. T. S. <gs...@ri...>]

And of course I forgot to actually attach the perl files...

-Greg

--
Gregory Stoll
gs...@ri...
"The story you are about to see is a fib, but it's short"
- Mathnet, "Square One"

[Config4gnu-developer] "flatfile" parser/unparser

[Gregory R. T. S. <gs...@ri...>]

Attached are my flatfile parser and unparser.  They work, but certainly
will have to be revised when we figure out how to better deal with files
like this.  Right now it just has a section (whose names are increasing
integers) for each line, including comments.  (which makes it ugly in the
frontend!) I added:

    <section sectionname="Boot modules"
             merge="xml"
             readcommand="parse.flatfile.pl /etc/modules"
             writecommand="unparse.flatfile.pl > /tmp/modules.new"/>

to config4gnu.xml under the "System" section.

Let me know if there's a better way to send such things out in the future.

-Greg

--
Gregory Stoll
gs...@ri...
"The story you are about to see is a fib, but it's short"
- Mathnet, "Square One"

Re: [Config4gnu-developer] Re: proposal for a syntax to identify a property

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

I see I'll have to explain in a little more detail :)

First, as you suggested, a method of escaping those characters should be
made available. Alternatively, we could allow users to quote the parts of
the path, in which case the quotes could follow semantics matching that of
the Unix shell.

Second, the brackets are an attempt to simulate the selection mechanism
available in XPath. XPath exists to identify elements in an XML document.

Inside the brackets you can enter criteria for which node to select. In
Config4GNU you may enter the criteria [comment=blah] would select the node
that has a property named comment and with a value of "blah". If you don't
specify a property name and the equals sign, it defaults to searching for a
node with the specified name.

So the fact that Samba uses brackets and that this path syntax uses brackets
is kind of coincidental.

Jason

[Config4gnu-developer] Re: proposal for a syntax to identify a property

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

For whatever reason, I've still not received the last 2 emails from the
developer list, so this email might not be treated as a proper reply...
Hopefully this has fixed itself. 


I have 2 primary concerns about your naming scheme.  The first is
"metacharacters" (the . and /) which appear in the names of sections or
other things.  For example, in apache, a <virtualhost> block has as its
"name" either a domain name or an IP, both of which contain a period. 
Also, not all sections are in []'s as w/ ini-style files, so I'm
wondering whether the []'s in the path to the node is specific to
ini-style or applies to all formats?

Finally, what about nested sections?  For example, in apache, a
virtualhost block can have a directory block inside it.  So would the
path be:

/Apache/www.example.com//cgi-bin/.value ?

Note the double slash, since often <directory> blocks have names that
include slashes.

I'd say that this could be fixed by escaping the / and . characters,
since trying to find a weird enough character that would never be used
doesn't seem like a good choice...  or maybe it is, I don't know.

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

[Config4gnu-developer] proposal for a syntax to identify a property

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

Justin:

To address the risk that Config4GNU's "wizard" design is too ambitious, I am
developing a prototype "wizard".

The wizards will be defined using an XML file that defines what pages and
widgets to display and what properties the widgets correspond to. The
definition file is generic enough that multiple front-ends can use it...
e.g. a web interface will generate HTML for the wizard.

The alternative to this approach is that wizards could be implemented using
a scripting language that generates the controls. A separate program will be
written for every front-end supported, but it saves the effort of creating a
one-size-fits-all wizard program.

The controls on a wizard need to be "bound" to actual properties that get
set or displayed. To bind the control, a property needs to be specified.
Following is a proposal for how a property might be specified.

--

The property identifier is a string, and it is called a "property path".

A "property path" is a "node path" and a name of a property separated by a
period ('.').

A "node path" is a sequence of "node identifiers" separated by forward
slashes ('/').

Nodes can be identified by their types and/or their names. A "node
identifier" is an optional "node type" followed by an optional "node name"
in brackets. At least one of "node type" and "node name" must be specified.

Here's a Samba example:

samba/[global].comment

This refers to the comment property in the global section of smb.conf.

samba means look for a node of type 'samba'. It doesn't matter what its name
is

[global] means look for a child node of the first found node with the name
of "global".

comment means select the property with the name of comment.

--

Jason