[Savannah-dev] [BACKEND] files parsing and related organisation

[Guillaume Morin]

Hi folks,

I've been thinking a lot on files parsing and the scripts organisations
that we are going to need.

I think that all data files must be XML to ease parsing in any language.
The structure that I suggest is <savannah> as root element and some
"role" children just as <configuration> or <dump>.

For instance, the first example of the config file draft looks like
(taken from the CVS savannah/backend/sava-lists/common/config.xml

<?xml version='1.0' encoding='ISO-8859-1' ?>
<savannah>
        <configuration>
                <lists>
                        <mailman usedump='yes'>
                                <directory>/var/lib/mailman/</directory>
                                <domain aliasfile='/etc/aliases-fsf' 
vhost='mail.freesoftware.fsf.org'>mail.freesoftware.org</domain>
                                <domain vhost='mail.gnu.org'>gnu.org</domain>
                        </mailman>
                        <mailman usedump='no'>
                                <directory>/com/mailer/mailman</directory>
                                <domain 
vhost='mailman.gnu.org'>ml.gnu.org</domain>
                        </mailman>      
                </lists>
        </configuration>
</savannah>


A multi configuration file would look like 

<?xml version='1.0' encoding='ISO-8859-1' ?>
<savannah>
        <configuration>
                <lists>
                        ...
                </lists>
                <dns>
                        ...
                </dns>
        </configuration>
</savannah>

A complete multi data file would look like :

<?xml version='1.0' encoding='ISO-8859-1' ?>
<savannah>
        <configuration>
                <lists>
                        ...
                </lists>
                <dns>
                        ...
                </dns>
        </configuration>
        <dumps>
                <lists>
                        ...
                </lists>
                <cvs>
                        ...
                </cvs>
        </dumps>
</savannah>

Enforcing this kind of structure allows every part of the project to
share the same data files if they have too. For example, that means that 
if a parser finds a list dump and some DNS related configuration
information in the same file, it will not scream. I really think we
should avoid mixing non related data but enforcing this will be surely
be helpful in the future.

The point of all this is to allow sharing of functions and data by
scripts written for different purposes.

For the backend, we should choose a language. Perl seems to be the best
language for it since most contributors know it and it can do every job.
I will have to provide some Python modules for Mailman. But Perl should
be mandatory for every new common API contributions. Special cases must
be discussed on this list.

Since every data file will share the same structure, I suggest to create
modules in Savannah::.

I plan to write :

Savannah::Common        that contains functions used by others modules
                                        such as controlling the well-formedness 
of a
                                        savannah configuration file.

Savannah::List          that contains a list related functions.

To apply that idea to  the first XML dump of this message :

some functions of Savannah::Common will ensure that the file is well
formed (the root of element is <savannah>) and will return a pointer to
the <configuration> childs in that case.  Some bits of Savannah::List
will then do their parsing job on the lists elements...


This is a proposition. I am not very experienced with Perl modules and
XML so I could have made design mistakes.

If you don't agree with any statements I made, please speak out now.

If no one expresses concerns on this, I will start the actual
development on these bases and enforce their respect.

Regards,

-- 
Guillaume Morin <address@hidden>

                Debian - What your mom would use if it were twenty times easier.
                            http://www.copyleft.net/