CashUtil: Outstanding issues.
Many of these problems are inter-related. Some would be easier to solve within gnucash, some can only be solved outside gnucash. Many require a different perspective on the current gnucash code, moving away from a GUI-only structure and reorganising existing code to separate GUI elements from object elements. Not all issues here can be solved in the source code.
Implicit in some of these issues is the desire to keep the cashutil front-end code generic so that it can be shared with other projects via QOF Generator and so that the cashutil objects can be easily transferred to other programmes with a different front-end. One of these programmes is likely to be an implementation of cashutil for embedded systems using GPE. See GPE Expenses which already uses QOF on an embedded platform.
Current issues to resolve within the cashutil source
Handling hierarchical objects
- The interactive shell logic needs to be able to edit
hierarchical objects intuitively. The "method of least surprise"
would be to use the Account name with a hierarchy separator, like gnucash:
It is preferable if this can be implemented at the object level, instead of within the front-end code.
Limited financial logic in cashutil
- Cashutil will not create data that is incompatible with the object but you might be able to create data that is financially inconsistent - non-existent accounts are the most obvious. GnuCash (via qof_book_merge) will deal with problems like that when merging QSF data back into it's own files but editing GnuCash files directly puts extra importance on the ancillary logic. CashUtil is therefore limited in the type of parameters and objects that can be edited, added or deleted. Multi-currency transactions and stocks/shares are unsupported and may produce unexpected results.
Implement gnucash assumptions as object logic
Deal with gnucash objects that are not QOF-compliant
Current problems in a shared or forked build.
Some src/engine files and src/backend files don't interoperate properly.
- This will be an ongoing problem. The only solution is to only update cashutil objects and backend code at discrete points in development so that incompatible changes can be folded into the codebase. The previous problem in gnc-backend-file.c has been resolved by allowing cashutil to be dependent on GConf2. This is acceptable because, unlike the original gconf, GConf2 has no GUI dependency and although nominally part of Gnome, it is installable without the rest of Gnome. i.e. it is similar to glib.
cashutil requires large amounts of other gnucash code, unchanged.
- Despite the small changes above, the bulk of cashutil code is common to gnucash. src/engine, src/business/business-core/, src/business/business-core/file, src/backend/file. Some files in src/core-utils are currently used but introduce more problems as core-utils is inherently gui-biased.
The common code is fundamental to both projects
- The CashUtil codebase is 3.5Mb. Of that, ~2.2Mb is common to gnucash - with some incompatibilities. The GnuCash codebase is ~90Mb. The problem is that the 2.2Mb that is common is the most important, most fundamental, code of both programmes. It would have to be split into FOUR shared libraries to satisfy the needs of both gnucash and cashutil - although those 4 could be packaged as a single dependency.
Leaving cashutil outside gnucash sources requires a lot of copying.
- This is nothing new, libqof has the same issue. It isn't easy to automate as the gnucash files needed by cashutil are not collated in the gnucash source tree, see above. CashUtil does use subversion to make this stage a little easier in the future.
User expectations differ.
- CashUtil isn't just a different front-end for gnucash, it provides a new way of interacting with gnucash data that differs fundamentally from the current functionality. CashUtil users want automated data entry, quick editing, full control over all details of data export and transformation. GnuCash users concentrate on the similarity with paper statements, standard reports and interaction with banking institutions.
GnuCash source files need to be regularly updated in cashutil
- The shared source files between gnucash and cashutil change frequently in gnucash svn. Not having the cashutil source in gnucash svn hinders the detection and solution of errors and problems inherent from the existing GUI bias.
svn externals do not solve the issue completely
- The gnucash directories needed by cashutil currently contain a lot of extraneous content that cashutil cannot use.
- Putting cashutil into gnucash makes it hard to keep the cashutil dependency list as short as keeping it outside.
cashutil requires the sql-parser from external libqof.
- This could be copied into the gnucash source tree. Although it adds another dependency to gnucash, it is likely that the SQL parser code will be used by future gnucash development anyway, e.g. sqlite backend. This is probably the smallest of the problems, overall.
cashutil requires different library structures / builds.
- libcashbusobjects.so, libcashobjects.so, libgnc-backend-bus.so and libgnc-backend-file.so. These are currently built as a complete alternative to the gnucash libraries: libgnc-backend-file.so, libgncmod-business-backend-file.so, libgncmod-engine.so etc. The conversion and testing of these libraries has not been done.
cashutil needs translation
- It would be easier for translators to have the cashutil source provide translatable strings to the gnucash PO file. cashutil has <200 translatable strings.
cashutil introduces new dependency on readline.
- A small problem but an extra dependency nonetheless. Probably not unexpected from a CLI. :-)
gnucash developers want cashutil within gnucash source.
- This ties cashutil to the gnucash release cycle. Problems in cashutil would have to wait for a gnucash source release rather than making an independent release from a separate source tree.
I want cashutil to be installable without gnucash.
- I see no reason why cashutil must be reliant on gnucash in a distribution package. cashutil and gnucash can share certain libraries, if the problems are resolved, but cashutil should not have any GUI dependencies.
- Data can be loaded from existing GnuCash 1.8 / 1.9 / 2.0 data files or from exported QSF files (which is why I wrote it in the first place). The GnuCash XML v2 backend is built into CashUtil and is being adapted, along with the financial objects and ancillary logic to work as a library that can be shared between GnuCash and CashUtil.
- CashUtil is also for data-mining using SQL and it outputs more QSF XML which can be used to make your own reports, invoices, print-outs, calculations, abstractions, databases .... whatever you like. You can use XSL, Perl, PHP, whatever you fancy.
- The data itself can always be updated from more recent G2 exports or data files - just save the SQL statements in a file and run them again.
- The QSF XML itself will be importable back into GnuCash too, eventually.