backend config

[Neil Williams]

On Thursday 18 August 2005 1:51 pm, Derek Atkins wrote:
> I was thinking that if the Backend Module *did* store its configuration in
> a GHashTable, then it could just return a reference to that HashTable
> instead of creating a new one to return.

OK, I'll add it to the struct so that if the backend library is in use by more 
than one frontend, each can have their own config.

> g_hash_table_lookup(table, key) returns a gpointer..  To what do I cast
> this gpointer in order to read the configuration option?  How do I do this
> programatically?

So along with the table/frame, you need the type and the key path / name. OK.

> I'd rather write a generic 
> configuration dialog and be able to plugin the config options into the
> dialog without requiring any new code in the UI.

Wouldn't we also need some form of text description of what that setting does 
(beyond just the cryptic name of the Kvp key path / hash table key string)?

> This means I need to know 
> the data types.  This could be done via a secondary (xml) schema, or it can
> be done in-band.

I'm all for XML - after all, this type/description data only needs to be read, 
not written, at runtime. It can be installed alongside the library as a 
static file, updated only when the library itself is upgraded.

<?xml version="1.0"?>
<qofconfig xmlns="http://qof.sourceforge.net/">
  <backend name="GnuCash File Backend Version 2">
    <provider xml:lang="en-GB">
        <option type="gint32" name="file_retention_days">
            Number of days to retain old copies of the file.
        </option>
        <option type="boolean" name="file_compression">
            Use compressed files or not
        </option>
    </provider>
    <provider xml:lang="de">
        <option type="gint32" name="file_retention_days">
           <!-- German translation -->
        </option>
        <option type="boolean" name="file_compression">
            <!-- German translation -->
        </option>
    </provider>
  </backend>
</qofconfig>

Slight problem there is translations. Although XML can cope with different 
language formats, it's not gettext friendly (AFAIK). The translations would 
need to be done separately. An added development burden.
:-(

It should be possible to use Perl to create translated XML from a .pl file 
that gettext can handle - that requires gettext 0.13
http://search.cpan.org/dist/libintl-perl/lib/Locale/TextDomain.pm

That's a build dependency only but from what I can check online, FC3 has 
0.14 !! (Found something I didn't know AND that works on FC3!) :-)

So, in the source, I'd have backend-config.pl as a source file and
<backend-name>.xml as an installed target. Gettext would then have to be added 
to QOF. Would that work? (The final XML would then only contain the one 
language - the local one.)

(Note that xml uses en-GB and can accept EN-gb too, when others expect en_GB!)

(Currently, QOF has no translatable strings, neither do the backends, so there 
is no gettext support in QOF, only CashUtil.)

Maybe one common detail per backend - the path to the installed XML file. Done 
in much the same was as the installed QSF schemas - the path would be part of 
the QofBackendProvider struct. The UI can pass that to libxml2.

Even if the user edits the XML, the backend will be OK (albeit using only 
defaults) as it will still only accept parameters of the type and using the 
key names expected.

It's up to the developer of the backend library to ensure that the XML and the 
backend are in sync - a once per release job. 

The UI then iterates over each backend, retrieves the common key/value pair to 
locate the XML - it should be able to pick up just the relevant translations 
from the XML by using the libxml2 parser.

As to whether this will be a hash table or a KVP - a hash table is fine if the 
types are declared elsewhere, a KVP provides robust type-checking: Hash 
tables accept absolutely anything which could be awkward, KVP limits the 
range of types and most should be usable. (Can't see KVP_TYPE_BINARY, 
KVP_TYPE_GUID and KVP_TYPE_GLIST being particularly useful - each config 
option should be standalone with it's translation but if the backend wants 
it, it could be done.)

On balance, probably KVP.

Phew!

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050818/87039ae7/attachment.bin