Sorting out QSF import and export

Derek Atkins warlord at MIT.EDU
Tue Jun 9 11:39:32 EDT 2009


Josh Sled <jsled at asynchronous.org> writes:

> David Goodenough <david.goodenough at linkchoose.co.uk> 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.

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.

> 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).

> 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.

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.

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.

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
-- 
       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


More information about the gnucash-devel mailing list