linux at codehelp.co.uk
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
> > 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 configure.in - 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:
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
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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050509/f732f4e9/attachment.bin
More information about the gnucash-devel