Redesigning the SQL integration for libqof2

Unsurprisingly, there is a deal of common ground between a SQLite backend and a GDA backend. Both need simple routines that convert library data into SQL statements but each has very different ways of reading that data back from storage.
I've spent today doing upstream work (whilst also getting my central heating system replaced). Gutted the house, gutted the library - what's wrong with that?
However, I've decided to make these new functions private to the library rather than exporting them. Simple reason really - they are one-way routines.
One day, QOF will support UPDATE statements and one day a bit later it will also support DELETE and even DROP but those require changes within the library like "unregistering" objects that the current code simply doesn't expect.
Eventually, this kind of SQL support can make a usable query interface for quicklist and a few other stalled projects (like DWI). The principle gain is to allow QOF objects to evolve and adapt but retaining compatibility will be a challenge. (QuickList is likely to only support a read-only mode for some objects and require that others are renamed before being amended.)
The other advantage of this refactoring is that the SQLite backend in libqof2 will be a lot smaller than before. Migrating the code hasn't increased the size of libqof2 either because so much deprecated code has been removed when bumping the SONAME.
I'm sticking with the roadmap of not looking to release libqof2 until after Lenny but that gives me plenty of time for internal reworking to get the GDA backend functional.
So far, I have been able to create a test GDA data source, add a table and data, delete the data and drop the data source. Not bad! (I test with SQLite but XML, MySQL, PostgreSQL and other ODBC connections are supported by GDA without changes to the QOF code.)
As ever, implementing new functionality needs a new test case so that has also been started - only 20 tests so far but worth doing.
Other changes before libqof2 - at the request of the original developer - will include updating QOF-Generator to work with libqof2, updating the old HTML example pages to provide a "QuickStart Guide" and other introductory documentation. Whilst I'm doing that, I'll probably also work on the Emdebian website documentation that also needs improved coordination.
Also note that pilot-qof and gpe-expenses are already libqof2 compatible. All that will be needed is some way for those to provide the username and password variables that some GDA connections would need. (The QOF GDA code already has support for such settings, it just needs to be implemented in the respective frontends.)
First set of changes are now in QOF CVS.
(Yes, CVS - I just don't see the appeal of all those new-fangled RCS versions - subversion is about as "modern" as I need. I just don't need the hassle that comes from git fanboys (or any of the other RCS versions) - nor do I need the hassle of migrating CVS to SVN.)
What I would say is that of the various SVN WWW interfaces, websvn stinks, view svn is a bit better but the only one I really like is Trac. For a single large project, Trac is much more friendly IMHO.