[Savannah-dev] XML dumps + file system (was: first thinkings)

[Loic Dachary]

Guillaume Morin writes:
 > Hi folks,
 > 
 > I thought on how we could organize the directories. 
 > 
 > 1) /etc/savannah/{module} for the configuration files
 > 
 > {module} will be defined later :-)

        Yes.

 > 2) /var/cache/savannah for the XML dumps

        I'd rather see /var/lib/mysql (if you see the dumps as an XML
database, it makes sense). Maybe /var/cache/savannah could be used for
partial dumps that are only needed for a short period of time. 

        There are two ways to produce the partial dumps needed, for
instance, for mailing lists:

        a) You can write a script that queries the database and produces
           an XML file conformant to the Savannah DTD(s).

        b) You can write an XSLT file that extracts from the full dump
           of the database the informations you need.

        As you probably guess I favor b) since that the way it's done
for XML files handling the account informations. There are various reasons
to choose b) over a), the most important IMHO being that you don't write
redundant scripts that will need to be updated every time you decide to
change something in the format. 

        One could argue that you'll have to change the XSLT file anyway
and that it's all the same. Except that XSLT is designed for XML file
transformations and you'll therefore have XSLT files that are smaller
than the equivalent software, hence easier to maintain. 

        One could argue that XSLT is exotic while perl programming is
common knowledge. My belief is that XSLT is something every hacker
wants to master because it is unique and tremendously useful
(transforming data). Since it's a standard; that Free Software
implementing it are widely available in a year or two from now it will
be common knowledge.

 > I think that every backend/www module should be configurable to use
 > either directly a SQL database or an XML dump.

        I'd vote for XML dump only. That is, assuming the backend
script is run by cron and produces effect on system services. In the
case of nss_mysql (for instance) that is directly connected to the
database, the role of the corresponding backend package will be to
properly configure nss_mysql to use the Savannah database and no
script will ever need to be run.

        The only thing you'll gain to maintain SQL + XML based backends
instead of XML is speed. And if speed matters you certainly want
to get rid of the backend scripts and plug the system service directly
to the database anyway. Therefore I think it's a waste of time.

 > I think that the description of all library functions that should be
 > used by the a significant part of the project should be announced here
 > for discussion.

        This goes without saying. However I acknowledge that a lot of
work is done by debian-sf, tuxfamily & all. Those are
packages/software we will eventually use but we can't really ask
everyone to comply to this rule ;-)

        Cheers,

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
24 av Secretan         http://www.senga.org/      address@hidden
75019    Paris         Tel: 33 1 42 45 09 16        address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt