QSF XML file backend for gnucash-gnome2-dev branch

Derek Atkins warlord at MIT.EDU
Wed Jan 26 15:02:40 EST 2005


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

>> >> Why?  You know that a transaction note maps to
>> >> <kvp type="string" path="/notes">
>
> It'd be <kvp type="kvp" path="/notes"> because each object uses "kvp" as the 
> definition for each of their *_KVP macros - at least so far.

Then how do you differentiate the different kvp types?

> Those will be within the "Account" or "Transaction" object so that's not a 
> problem, but it does remind me about object name collisions that we discussed 
> earlier.
>
> Is it possible to change 
> #define GNC_ID_ACCOUNT        "Account"
> etc. to
> #define GNC_ID_ACCOUNT        "GNCAccount"
> etc.? (or similar, just a standard prefix for all GnuCash objects - maybe gnc_ 
> or GNC- ,gnc- . .  ) in gnc-engine.h ?
>
> Are there any situations where the word is used instead of the macro?

*ponders*

There are certainly places where the string-values are used (read:
stored).  So changing some of these might be a bit problematic.  For
example it would screw up any "stored" queries.  What I don't know is
if any of these strings are used in the gnucash xml data file.

However I dont think this would be a major issue in the G2 branch,
unless these strings are used in the XML.

> I've used 
> #define PILOT_LINK_QOF_EXPENSES "pilot-expenses"
>
> It's only the objects that need to avoid name collisions between applications. 
> It's not a problem now, I'm just thinking ahead - before too many files get 
> written using a QSF tag name that then changes.

Why not put an "application" tag at the top of the QSF tree so you
know which application wrote the file.  Then you don't have to worry
about object collisions, just application collisions.  This way an
"Account" in a "GnuCash" app context can be different than an
"Account" in a "PilotExpense" app context.

>> That's sort of what I thought it would be in the first place, which is
>> why I didn't understand why it was so hard.. ;)
>
> It was the nesting. By reproducing that in the path="", it's OK. Just needs to 
> be thought through.

Ahh..  Yea, the kvp namespace can always be flattened out.  You can't
have you objects at any particular node, so if there's a subtree at a
particular node you know there isn't some other data at that node as
well.  E.g.., if you have /foo/bar/baz = <string>"quux" you know that
/foo and /foo/bar are "frame" objects and cannot be anything else.  So
you could flatten out the three nested kvp objects into a single flat
object.  I.e., you only need to store the leaves (with full paths),
not the branches.  :)

> I'm fast running out of time this week though. The replacement patch may be 
> this weekend now.

Oh well..  You'll get it done when you get it done.  :)

-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