QOF->GObject Plan

[Josh Sled]

On Wed, 2006-12-20 at 16:10 -0600, Daniel Espinosa wrote:
> May is time to consider to deprecate the actual File backend and
> construct some utilities to automaticaly convert this to a SQLite file
> (it isn't a trivial XSLT convertion but a set of functions to get the
> data and store it to the database using GDA).

I don't know about May ... how about "when it's ready."? :)


As discussed not too long ago on the list, you can't ignore the GUIDs in
deference to the databases's identity datatype.  The GUIDs *are* the
object identity, even in the database.  Alos, because of how they're
used throughout gnucash, they need to be stable over the lifetime of the
object.

I'm not sure why functions like KvpFrame[...]get_double wouldn't be
implemented.  Even if they're not used, it does complete the
interface...

I'm not sure why functions like KvpValue[...]new_binary would move to
another source file: the KVP code should encapsulate its structure, and
I don't see how that happens if other source modules need to know about
it.


(There's probably more comments to be made, I'm heading out of town for
the holidays ...  I'm sure others are preoccupied with the same as
well.)

-- 
...jsled
http://asynchronous.org/ - a=jsled;b=asynchronous.org;echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20061222/ae003c8d/attachment.bin