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/
pgpkm6hB1AQGY.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
