command-line utility.

Neil Williams linux at
Mon May 9 16:06:05 EDT 2005

On Monday 09 May 2005 5:06 pm, Josh Sled wrote:
> On Mon, 2005-05-09 at 08:53 +0100, Neil Williams wrote:
> > In effect, it becomes a data mining utility - working from exported XML.
> > It would operate separately from GnuCash - it would neither access data
> > files created using the GnuCash v2 xml nor interfere with a running
> > GnuCash process. (Although I suppose it could do one or both if that was
> > desirable.)
> Um.  What _would_ it read, then?

If it's standalone, it would read XML exported by GnuCash. You'd export a 
large file - an entire book, all invoices, all accounts - depends how much 
fine tuning I can make within the GUI before G2 is released - and let it work 
on that. It would also be able to combine files from different sources.

Once G2 is out and I've time to work on a more powerful GUI export, the CLI 
would be used for data mining, pipes, scripting and handling certain queries 
that simply cannot be done via a generic GUI - like querying objects from 
another application.

> > Should this be (yet another) stand-alone project (which would mean
> > copying the QOF objects and keeping them in sync manually) or can it be
> > included in the main GnuCash build (reducing it's size and complexity
> > *considerably*)?
> Certainly making _more_ copies of QOF source is a bad idea...

If it was going to be stand-alone, it would link against QOF which will be 
released as a package before G2 and will be available separately (at least on 
Debian). I'm not copying any more QOF source into any trees except GnuCash. I 
am keen on having GnuCash linked against QOF as a shared library on all 
platforms in the future as well as GnoTime. I see little reason to perpetuate 
the copying of QOF source into the GnuCash tree much after G2. If there are 
features missing from QOF that are preventing that move, let me know and I'll 
see about adding them. There's more to do to finish what I've done so far 

I'm working on QOF to flesh out the codebase, remove redundant code and 
generally make it usable to a wider range of processes. I'm also working on 
it as a package as co-maintainer for Debian. I'll work with any of the 
maintainers for other platforms should they decide to create a libqof RPM or 
other package. I have a package of my own that depends on qof as a shared 
library and I am confident of completing the spin-out. GnoTime on Debian will 
also use the shared library - even though the old v0.4 QOF source is included 
in CVS - as soon as QOF v0.5.2 is released.

It's not a lot of work to get this CLI utility to read GnuCash XML files - if 
it's part of the GnuCash tree then it'll find the backend quite easily. It 
could then read the data direct. It would not be affected by using QOF as a 
library. Once G2 is out, I'm sure GnuCash would work with libqof too. I aim 
to make it as simple as a patch to - all the objects would 
remain in place, the QOF code in /src/engine/ and backend/qsf/ would 
disappear into the library.

> I'm all for a GnuCash CLI tool to interact with GnuCash data using
> GnuCash semantics and idioms.

It will, it would use the names #define'd in the GnuCash headers and set out 
in the QofClass parameters. Object names, parameter names - all as per the 
GnuCash source. Equally, QOF itself deals with objects with their own names 
from GnoTime or pilot-link etc. I'm hoping to spread that out to more 
applications and if, someday, QOF becomes an important library within Gnome 
as a whole, I'd be well pleased!

> And while I can see the benefits of 
> having a generic CLI QOF-query tool, that seems like a tool to live in
> the QOF source tree rather than the GnuCash source tree, and I'm less
> enthused about it in general.

OK. However, consider QOF as the portal to a free data set - liberating the 
user data from the application, any application. That's my motivation - I 
want a universal data set, generic data available on demand to whatever 
process requires it, without import/export filters or opaque file formats. 
Then QOF becomes more than just the query tool, it becomes a query tool 
providing an interface to a range of applications and environments, even 

It's easy to build on customised reports, data mining, data translation . . .

I want users to be able to process their data without limitation. QOF is not 
the only solution, but it can be a part of that.

I've set out my ideas on that here:
and here:

There is still a good chance of QOF being used for inter-process communication 
on embedded systems.

> I've seen a GnuCash command-line tool as a useful thing to create in the
> next-two-releases timeframe, if only because working towards it will
> help seperate out the actually application/"business"-logic from the GUI
> code, which is an important medium-term architectural goal for us.

I agree - with QOF as a shared library, all manner of possibilities open up.

Currently, GnuCash has QOF for the data handling engine, Gtk for the GUI and 
Scheme for the reports. OK, that's over-simplified, I know.

By spinning out QOF, all those requests for customised reports, unusual export 
formats, "will GNC work with X app", all that stuff can be handled 
externally. Let GnuCash concentrate on the objects and the reports that 
everyone needs and hand-off customised data processing to QOF, XML and 
scripting tools.

That is how we'll add inventory, payroll, EPOS and other functionality onto 
GnuCash - by wrapping those programs in QOF. In turn, GnuCash should be able 
to exchange data with Gnumeric, Evolution, Kontact, Outlook, Notes, Exchange, 
a whole host of applications that can provide or utilise data currently held 
or re-entered in GnuCash.

I know it's ambitious, but it's also an interesting challenge!


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :

More information about the gnucash-devel mailing list