Dirty entity identification.

[Neil Williams]

On Friday 22 July 2005 3:07 pm, Chris Shoemaker wrote:
> ?!?  Are we talking about the same project?  Gnucash?

:-) Yes.

> 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: 

C files:
gnc-date.c		gnc-trace.c		md5.c		qofchoice.c
qofinstance.c		qofquerycore.c		qofsql.c        
gnc-engine-util.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

H files:
gnc-date.h 		guid.h			qofbackend-p.h	qofclass.h
qofinstance.h		qofquerycore-p.h        
qofsession-p.h
gnc-engine-util.h
kvp_frame.h		qof-be-utils.h		qofclass-p.h	qofinstance-p.h
qofquery-deserial.h 	qofsql.h
gnc-event.h
kvp-util.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 
layer.

> 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 
watermelons!

> > > 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),

True.

> 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.


-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050722/5fab9e5b/attachment.bin