QSF progress.

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> Does gmodule refer to the GnuCash 1.8 method, a Glib method or the Gnome2 
> branch?

gmodule is the glib2 module api (sort of like how gobject is the glib2
object system).

> This backend_library through QofBackendProvider is what Linas has setup for 
> the DWI backend for QOF and hence that's how QSF will be built onto 
> pilot-link and other applications - as an entirely QOF build. 

Ahh, if Linas already has the infrastructure then ok.

> How is SQLite going to be built onto GnuCash? Are we using QOF or a direct 
> bind? i.e. are gncCommodity and gncPricedb etc. going to be overhauled before 
> SQLite or will the GnuCash QofBook still require additional, specialised, 
> handlers? The 1.8 GnuCash file backend (via sixtp) uses secondary parsers for 
> certain objects that are not directly readable via QOF - will this continue 
> or will everything be read via QOF into SQLite?

I'm fairly confident that SQLite will be a Gnucash Backend, not a QOF
backend.  But I don't know for sure.  I think it's going to depend on
who implements it.

> Writing a QSF file from a QofBook was made very simple by only requiring one 
> set of handlers. Book, object, parameters - 3 callbacks, 3 foreach loops and 
> it was done. I'd love to see the same with GnuCash and SQLite - to me, it's 
> the only way to have truly portable GnuCash data - it should all be definable 
> through QofObject and QofClass.

Except I don't care about any other application reading the SQLite
database.  Also, it would mean we can't add stored procedures or use
any special indexing tricks in the database if we have to abstract it
through QOF.  I'm thinking of the SQLite Backend in the same way that
gnucash thinks about the Postgres Backend.

> To determine the file type for all with one function? Yes. I don't know the 
> SQLite file format but the schema validation will separate QSF from all other 
> file formats. 

Yes, that's what I was hoping for -- a single function that could
detect the actual file type and handle it accordingly.

> SchedXaction.c doesn't define any QOF objects although the main struct does 
> use QofInstance so currently, scheduled transactions are not supported by the 
> merge code or QSF.

So what happens if you try to merge a QofBook that has an SX?

> In order for a QofBook object to be accessed by either the merge code or QSF, 
> the QofObject definition must have a create: and a foreach: definition and 
> the QofClass parameters must include sufficient parameters to create a fully 
> functioning object with only QofAccessFunc and QofSetterFunc. I'll look at 
> that once I've got existing objects working fully - i.e. fixed this problem 
> that shows up in xaccGroupGetNumSubAccounts.

Well, this GroupGetNumSubAccounts problem could be occuring due to
SXes being improperly attached to the CoA AccountGroup instead of the
SX AccountGroup.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available