[Libconf-dev] None

[dams]

Sender: address@hidden
From: address@hidden
To: address@hidden
Cc: address@hidden
Subject: Re: neoLinuxConf
References: <address@hidden>
        <address@hidden>
Date: 27 Mar 2003 14:03:19 +0100
In-Reply-To: <address@hidden>
Message-ID: <address@hidden>
Lines: 43
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Aidan Delaney <address@hidden> said:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I havn't had much time to write what I proposed, but here's a very short 
> synopsis of what I want to say.  Is it like what your currently doing?  I 
> will write more in the next week.

Ok I've read the attachment, your plan is (correct me if I'm wrong) basically
to have a common language for all config files, and a unique engine to parse,
read, and modify them.

Our vision is different, we have 3 layers

libconf : it's a parser and a set of templates per config files family. libconf
is used to parse the config files, and represent them in a common data
structure. One can then change the datastructure, and write the config file
back. There are powerfull functions to handle the structure.
example : $xf86Config->getAtom($xf86Config->findAtomPos( { Device => 'matrox
g400' }));

glueconf : it's a layer on top of libconf, it maps the libconf data structure
of each config file (and not a family anymore) on an easier to use structure,
so that it's easier and natural to modify a config file.
example : $xf86Config->{Device}{'matrox g400'}{VideoRam} = '64M'

systemconf : it's a set of scripts that adds linux distributions specific
functions to modify the system configuration. Each script will touch more than
one config file
example : addNewVideoCard('X11,framebuffer','g400',...)

libconf is done, glueconf is nearly done, systemconf is not coded at all.


The way we do it are different, but we could merge. libconf could have a
template for neo-linuxconf, and output the config file in your syntax. If your
language/syntax is well advanced, we could take it as a replacment to our
glueconf representation...


-- 
dams