CashUtil, budgets and history

[Neil Williams]

The following is just a summary of my ideas on how CashUtil could share 
financial logic with GnuCash - with as few changes to the source tree as 
possible and retaining as much CVS history as possible (seeing as we are 
using CVS not subversion).

None of this is urgent or fixed, I'll be using CashUtil as a QOF test routine 
for some time yet. It's just that when work commitments reduce the time for 
writing code (as this week), I tend to plan the next stage in the quiet times 
at work.

With the exception of the files to be moved into lib/qof, this *could* leave 
existing .c and .h files in their current locations, so preserving CVS 
history for the business objects, the v2 backend etc.

The full list of files involved so far, is here:
http://www.linux.codehelp.co.uk/cashutil/gnucash.html
(The tables list those files in src/engine that are part of QOF, those across 
the G2 tree that are needed currently by CashUtil with their current GnuCash 
(G2) locations and those in src/engine that are not needed by CashUtil 
(including those that cannot be part of CashUtil) or where CashUtil locations 
are undecided.)

The GnuCash XML v2 backend is also required but not listed explicitly. By 
building that library in the existing tree, I believe it can follow the 
pattern of the src/engine objects and src/business/business-core objects: 
Build one library in each location and then combine the two libraries into 
one for use with CashUtil and/or GnuCash.

Current hypothesis:

1. Those files that redefine QOF functions, defines or types with GNC prefixes 
can be retained by GnuCash (possibly deprecating the old names?) and ignored 
by CashUtil. I'd patch any calls in the files to be shared with CashUtil that 
use the gnc prefix.

2. CashUtil is testing with a single object library that instead could be 
formed from two shared libraries, one built in src/engine and one in 
src/business/business-core.

3. The G-Wrap files can still be generated in situ - as long as they are then 
compiled into a separate library that is not linked against CashUtil.

4. Scheme specific code could be treated like the G-Wrap code.

5. Budgets may or may not end up in CashUtil - it may not be appropriate to 
port Budgets to a CLI. (This would be non-trivial to incorporate into 
CashUtil as budgets are not QOF objects - Personally, I don't see budgets 
being that useful in a CLI.) Comments? 

6. The gnc-engine module would be GnuCash only - if it is still used. It could 
incorporate the same libraries as CashUtil with the extra code from these 
excluded files.

7. The files from gnucash/src/engine that are also in QOF would be moved (at 
some future date) from src/engine into lib/qof and later removed completely 
when GnuCash links against QOF as an external library.

8. Further changes in the GnuCash XML v2 backend (possibly split in the same 
way as the object library between src/backend/file and 
src/business/business-core/file) will remove the need to load the current 
backend using GnuCash specific code - it could be loaded in the same manner 
as QSF. (This will be necessary to use QOF as an external library.)

9. Using the business objects as a separate library could offer the ability to 
retain the current Business module for GnuCash whilst integrating the 
business objects tightly into CashUtil.

Note:
None of the above has yet been tested in a real tree and some of it may never 
work, it's just a set of ideas. It's just a starter. Feel free to pick holes 
(constructively).
:-)

To partially answer Derek's earlier question, I also have a better idea of 
what is stopping CashUtil from currently being built within the GnuCash tree 
(most awkward first):

a. qofsession.c uses GnuCash #define's to load the v2 backend. The system for 
loading that module isn't likely to be supported by CashUtil, instead I'd 
like to make the v2 backend into the same type of library as QSF and load it 
via the same mechanism (within CashUtil AND GnuCash.)

b. Some way of handling gnc-trace so that it knows which package it is 
tracing, as this will be a QOF file.

c. Adjustments to the Makefiles to remove Scheme and G-Wrap source from 
libraries to be shared and create new libraries that contain this code for 
GnuCash to use.

d. gncCommodity.

This is not a complete list, just issues I have found so far - some of these 
are admittedly trivial / expected.

I'm beginning to wonder what I've started and whether there's sufficient time 
to get it ready for G2!

The CLI is an eagerly awaited feature. Some users could come back to GnuCash 
once a CLI is available. I want to get it as usable as I can and as reliable 
as possible. It would be better to release G2 and then the CLI as a part of 
2.1 rather than release a sub-standard CLI that disappoints such expectant 
users. However, I will try to get it ready for G2.

If anyone else fancies joining myself and Daniel on this task, please contact 
me!

(please?!)

-- 

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/20050801/0480571c/attachment.bin