Dirty entity identification.
linux at codehelp.co.uk
Fri Jul 22 11:13:11 EDT 2005
On Friday 22 July 2005 3:07 pm, Chris Shoemaker wrote:
> ?!? Are we talking about the same project? Gnucash?
> Let me try to focus on the heart of the disconnect. The "offline
> backend" was just one fictional example of a case where the knowledge
> of financial relationships makes the difference between a reasonable
> and unreasonable implementation. The real issue here is your
> insistence that gnucash's "engine" has no concept of financial objects
> or their relationships. Maybe there's a terminology mismatch here.
> By "engine" I meant the code under src/engine/.
By engine, I mean QOF. There is a difference there and it relates to the
objects. In src/engine, we have various objects that are central to GnuCash,
Account, Trans, Split, Lots. Those are not part of QOF. Those, together with
the business objects gncInvoice etc. in src/business/business-core/, comprise
what I think of as the "Object Layer". A layer of code that is between the UI
and QOF. It represents the majority of the financial logic, it represents
everything that these objects can and cannot do but it is not the sum of the
financial logic in GnuCash. It is distinct from QOF and this will become
v.clear when QOF is used as an external library.
I'm sorry if this wasn't clear. It comes from working with QOF as an external
library with non-financial objects, the dividing line becomes clearer than if
you look at it from within GnuCash.
In src/engine, some of the gnc-*.c|h and all qof*.c|h are QOF. The files with
capitals are not. Unfortunately, there are other files in src/engine (like
the budget) that don't fit this pattern and there are files like kvp* and
md5* that ARE part of QOF. There are also historical headers that redefine
QOF functions as gnc functions which confuse things more.
Here's the contents of the QOF equivalent directory:
gnc-date.c gnc-trace.c md5.c qofchoice.c
qofinstance.c qofquerycore.c qofsql.c
guid.c qofbackend.c qofclass.c qofmath128.c
qofquery-deserial.c gnc-event.c kvp_frame.c qofbook.c
qofgobj.c qofobject.c qofquery-serialize.c
gnc-numeric.c kvp-util.c qof_book_merge.c
qofid.c qofquery.c qofsession.c
gnc-date.h guid.h qofbackend-p.h qofclass.h
kvp_frame.h qof-be-utils.h qofclass-p.h qofinstance-p.h
qofbook.h qofgobj.h qofmath128.h qofquery.h
gnc-event-p.h kvp-util-p.h qof_book_merge.h
qof.h qofobject.h qofquery-p.h
gnc-numeric.h md5.h qofbook-p.h qofid.h
qofobject-p.h qofquery-serialize.h gnc-trace.h qofbackend.h
qofchoice.h qofid-p.h qofquerycore.h qofsession.h
Using QOF as an external library, all these files would be removed from
GnuCash src/engine with no loss of function. It's not ready for that yet and
it those areas where I'll be working on the GnuCash code.
None of the *-p.h private headers will be available to programs linked against
QOF and that is where I will be enhancing the API to allow changing the
current GnuCash code to use the API instead of private headers.
There are issues here, notably about who controls gnc-trace.c and I'll be
looking at ways to pass the identification of the app to gnc-trace so that
GnuCash can still produce GnuCash trace logs instead of qof.trace. That
shouldn't be too hard.
> The lack of a relationship between Transaction and Account is not
> evidence that there is no "tree" in the source code.
(There is no tree, trust me!)
> You keep saying that the financial relationships can't be in engine,
Because those are defined in files like Account.c that are in the object
> because QOF doesn't know a Split from a Watermelon,
:-) Honest, it doesn't. QOF can quite easily cope with a book of biological
classifications of watermelons! It could cope with a whole range of data -
the only things I'm not sure about supporting so far are v.large amounts of
unbroken text and binary data.
> ??? The "engine" you're talking about is not src/engine/.
No, it's not, the engine is QOF. That's why the object layer needs to be part
of this intermediate library used by CashUtil so that CashUtil is talking the
same language (i.e. using the same objects) as GnuCash, unlike my other QOF
applications that could be dealing with pilot-link datasets or GnoTime or
> > > In your view, where exactly are those relationships best represented?
> > 1. The UI display
> > 2. The docs
> > 3. The minds of the developer and the user.
> I expected you to add 4. OBJECTS.
There are relationships in the objects but they don't form a tree.
> Um. Those financial relationships are a pretty important part of a
> financial app.
Hence the intermediate library. They are of no use to pilot-link or GnoTime -
QOF really doesn't care so they need to be elsewhere. The sensible place is
where GnuCash and CashUtil can use the same source whilst allowing CashUtil
to be installed without GnuCash.
> And they need to exist in *code*, in the data
> structures (which they currently do, BTW),
> and preferably not in GUI
> code. If you want to call something an "engine" that has no concept
> of financial relationships, fine. There still needs to be "a library
> of core inter-related financial data-structures and the operations
> that manipulate them, using those relationships."
That's what I want to have as an intermediate library.
> Currently, that's
> src/engine/, but we can call it something else if there's a consensus.
And elsewhere, otherwise the library would be easy. GnuCash, now, wouldn't be
the app it is without the business objects so these cannot be left out of the
CLI. It's the other logic, currently in areas of the UI, that will take a
little time to identify and sort.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050722/5fab9e5b/attachment.bin
More information about the gnucash-devel