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 [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
