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