Transaction GUIDs [Was: Writing a Sharp Zaurus PDA GnuCash Companion]

[Colin Pinkney]

I was just looking at how GUIDs are generated, but couldn't quite figure it
out. Seems to  have something to do with randomly selecting md5sums of
files that constantly change.

I'm know very little about pseudo-random algorithms and want to keep it
simple so I'm hoping /proc/sys/kernel/random/uuid has enough entropy. But I
guess in the end as long as it's a unique 128bit number (stored in hex
format) it doesn't really matter, does it? Must the uniqueness apply to all
transactions within a data file or just for a particular account?

Thanks,

Colin




Josh Sled <jsled@asynchronous.org>@lists.gnucash.org on 21/08/2002 16:19:45

Sent by:  gnucash-devel-admin@lists.gnucash.org


To:   Colin Pinkney <Colin.Pinkney@marconi.com>
cc:   Derek Atkins <warlord@MIT.EDU>, gnucash-devel@lists.gnucash.org

Subject:  Re: Writing a Sharp Zaurus PDA GnuCash Companion


On Wed, Aug 21, 2002 at 10:53:53AM -0400, Derek Atkins wrote:

| The documentation is relatively ad-hoc.  I don't know if
| there is a schema/DTD.  We certainly don't use one during
| the read/write operations (we build the XML by hand).

There is some DTDage in src/doc/xml/, but it's bitrotted comparred to
the code [in src/backend/file/].

| "Colin Pinkney" <Colin.Pinkney@marconi.com> writes:

| > The idea is to use the same file format so that it will then be
relatively
| > easy for me to write a sync conduit to synchronise the PDA and desktop
data
| > files. I use GnuCash on my Linux PC all the time so I've had a look at
the
| > data files and it looks relatively straight forward, but it would still
| > help if there were some documentation on the file format. Is there any?
Is
| > it using a standard XML schema/DTD?

No standard schema, yes on the DTD, though as Derek says the DTD files
are not used for parsing or generation.

The main thing that would need to be synchronized is the GUIDs,
specifically
for accounts.  And, ensuring that the Sharp side is going to respect the
engine constraints.

If you're not using CVS you should be; the modules infrastructure/approach
in CVS will let you use the engine module [and even the backend module]
independently of the UI, reports, SQL backend, &c.  This might save you
some time in the long run, while levaraging work on the existing code base.

But I'm not quite sure what you mean by a Zarus companion app... does it
provide targeted functionality [expense tracking], or are you attempting
to get as much GnuCash functionality as possible, but on the Zarus?

...jsled

--
http://www.asynchronous.org - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
jabber:jsled@jabber.asynchronous.org, ICQ:4983267, {AIM,YIM}:joshsled
_______________________________________________
gnucash-devel mailing list
gnucash-devel@lists.gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel