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? > 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... I'm all for a GnuCash CLI tool to interact with GnuCash data using GnuCash semantics and idioms. 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. 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. ...jsled -- http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel