Sorting out QSF import and export

David Goodenough david.goodenough at
Tue Jun 9 12:28:54 EDT 2009

On Tuesday 09 June 2009, Derek Atkins wrote:
> Josh Sled <jsled at> writes:
> > David Goodenough <david.goodenough at> writes:
> >> So the question is, which way to go.  Should I simply work on the old
> >> QSF code and get it to work, and then add selection to it and matching,
> >> or should I look at the new framework and rewrite the QSF code to work
> >> there?
> >
> > QSF is a bad idea.  Please don't propagate it.
I am not wedded to QSF, I am wedded to an XML import/export which can then
be trasformed using XSLT into whatever other XML format might be 
> This is where Josh and I disagree..  I don't believe it's completely
> a bad idea, but I believe the what's there is poorly done.  The concept
> of a generic XML that can encode and parse generic objects is a good
> idea IMHO.  But what's there is... limited.
I agree with this.
> > Domain-specific import/export formats and import/export logic are going
> > to be far easier to implement, debug and use.
> Maybe..  Keep in mind that the information in an import object is not
> necessarily the same used internally.   Yes, one COULD use the GNC XML
> object formats for import/export, but you'd still need to recode
> the I/O to handle import objects differently (e.g. lack of a GUID).
Where is the GNC XML format defined?  I have some ideas that I have
used elsewhere to fix the GUID problem.
> > Hopefully, you can find something to leverage in the existing (generic,
> > not QIF-specific) importer/exporter, but for things like Customers and
> > Vendors where there's not an src/engine/Account to match against, I'm
> > not sure if the existing code will be trivially adaptable; those Vendors
> > and Customers are different data-sources for matching purposes.
Well there can be a match, it might not be by ID, but it might by some
other field match.
> I doubt that any of the existing importer code will help with
> any of the business objects.
> > Note that I'm speaking at a high-level, I'd be happy if you found the
> > code was more sophisticated than I'm thinking.
> The existing code was pretty sophisticated in that you could plug
> in various matching rules per object and such.  But it was very buggy,
> and it's been a long time since I've looked at it.
Are you talking about the QSF code, or the other import/export code?
> David, you should ignore external QOF.  It went off in a completely
> different direction and at this point I don't think it would be trivial
> to do a merge.  And we're not at all interested in a merge because
> frankly we've put a bunch of bug-fixes into the code and the last time
> we had a merge those bug fixes were lost.
> As for pulling up their QSF -- that COULD be an option, but I don't
> think that the majority of work is in the QSF backend but rather in the
> GUI frontend.
If there is a viable alternative I am happy to go with it.

> There *is* QSF Import UI, but it's just not hooked into the Menus.
> Take a look at ./src/gnome/gnc-plugin-basic-commands.c and in particular
> the macro QSF_IMPORT_WORKS
> -derek

More information about the gnucash-devel mailing list