[OPEN-ILS-DEV] Proposal: Versioned Add-on Packages

[Dan Scott]

2009/2/20 Mike Rylander <mrylander at gmail.com>:
> In order to make extending Evergreen data structures as straight
> forward as possible, we use an abstraction layer that has at its heart
> an XML file called, by default, fm_IDL.xml.  This file describes the
> structure of and relationship between objects that Evergreen's
> component applications have access to, and tells the storage subsystem
> how to get to the underlying data stored in Postgres.  All database
> interaction is driven and directed by this file, and there are
> explicit provisions built into this abstraction layer for the purpose
> of extending the stock database schema with custom tables and views.
> Local customizations can also be made to existing objects, extending
> them in ways that allow local persistent fields to be added, and new
> relationships to be described, all without changing any existing code
> that uses these objects (with the exception of removing existing,
> in-use fields -- that would be bad, m'kay?).

<snip>

> In order to integrate the content of these files into the main IDL, I
> propose that we change the name of the stock IDL file to
> fm_IDL_base.xml.  Then, we extend autogen.sh such that it takes the
> content of each file in the extension directory and adds it under the
> root node of fm_IDL_base.xml (taking care to avoid replacing entities
> with their literal counterparts), generating an entirely new file
> which will be placed at fm_IDL.xml.

I'm thinking about the corresponding i18n process (of course!).

For most purposes, the content inside the copy of fm_IDL.xml that
lives in /openils/conf/ does not need to be translated. The exception
is the reporting interface; we currently extract all of the
reporter:label attribute values and generate an en-US POT file that
can be translated into other languages. At build time, that POT file
is turned into a DTD, and all of the reporter:label attributes are
turned into corresponding entities in the copy of fm_IDL.xml that
lives in the /openils/var/web/reports/ folder (and that file includes
the DTD so that mod_xmlent can translate the reporter labels into the
desired locale).

I suppose the process doesn't have to change significantly. We could
teach the reporter:label extraction script to parse all of the
extension IDL files (it is a bit more complex if they end up living in
the ILS-Contrib repository, but it can be done). We could generate one
POT file per extension IDL file, then build the corresponding DTD
files.  We would have to teach autogen.sh to create the entity-ized
version of fm_IDL.xml in /openils/var/web/reports/ and to include each
DTD file per extension that is included into the header of the
entity-ized fm_IDL.xml. Teaching autogen.sh this trick might be the
most time-consuming piece, as all of the I18N scripts are currently
written in Python and involve packages that are only necessary for the
release manager or translation mangler to have installed on their
system.

-- 
Dan Scott
Laurentian University