warlord at MIT.EDU
Wed Mar 5 10:58:48 CST 2003
Andrew Pimlott <gnucash-devel at andrew.pimlott.net> writes:
> I would hope that the data model would be sufficiently normalized
> and constrained to make direct access reasonably safe. I consider
> this is an entirely reasonable goal (and as I said, I would be
> interested in helping).
It's not really a question of normalizing the data -- the problem is
that gnucash has a number of invariants that, AFAICT there is no way
to enforce in a database.
> I have tried and unfortunately ran into difficulties. I would much
> prefer to use Scheme than C, however the Scheme bindings do not seem
> to be very well maintained (aside from the parts needed for
> reports), and are at any rate very C-like (sometimes they would even
> seg-fault :-) ), which makes them less pleasant to use. And when I
> tried to use some functions outside the engine, I found that they
> made assumptions about running under the UI. (I know, this all
> could be fixed, but it seems like a big job, and I don't think I
> want to do it.) Last, much of the API is undocumented, or the code
> has evolved apart from the documentation (from what I could tell
> perusing the src/doc directory).
Then by all means, use scheme. Using scheme should be REALLY easy
with the 1.8 codebase -- in fact even "gnucash" is a scheme program!
As for how the scheme code looks, well, the "scheme code" really is is
just wrapped/exported C functions, so it's not at all surprising that
it could segfault. It tries not to do so, and if you do find places
that segfault it should be reported as a bug (all exported C functions
should check their arguments).
Admittedly the API documentation is out of sync; but you can look for
gw-*.html within the build tree for all the g-wrapped functional
> Maybe I will go back and give it another shot, but my early efforts
> were slow going. This led me to decide that talking SQL would be
Well, it all depends -- are you sure your data is stored in SQL? Are
you completely writing off people who use the XML/File backend? Or
the RPC backend (even if it doesn't work)? Or....
> I don't mean to be too critical: the engine is indeed well separated
> and is clearly, at the core, a clean design. But I have to admit
> that when I look at a function starting xacc and see a bunch of
> calls starting gnc_, I wince a bit.
I would hope so. The Engine Library is extremely standalone. You
should be able to pull in the engine, app-utils, and backend modules
without pulling in any UI functions. If this is not the case, then
it's a critical (IMHO) bug and needs to be fixed.
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