Should GnuCash use an external QOF library?

[Chris Shoemaker]

[Warning: Long...  and probably not as tactful as Christian "this
statement lacks a bit of diplomacy" Stimming.  :) ] 

Neil,
        In the interest of time, let me jump right to what I think is
probably the most fundamental and, perhaps, controversial of several
slightly-related topics:

        Should GnuCash use an external QOF library?

        Making a library out of code that solves a common problem so
that multiple projects can use it is an attractive goal.  I think
there is a "QOF concept" that finds meets that requirement, and so, I
am, in principle, a supporter of lib-ized QOF.

        However, I've been increasingly uncomfortable with how things
are looking *in practice* for about a year now, as I think several of
my emails evidence.  For most of that time, I attributed that
discomfort to my own lack of understanding (I'm often a bit
uncomfortable with things I don't quite understand.)  But, by now,
I've read most parts of QOF several times, and I understand QOF MUCH
more thoroughly than I did a year ago.  Nevertheless, I'm still
uncomfortable with the library spin-out.  Why?

        Well, for one, I think you've been too expansive in drawing
the abstraction boundary around QOF.  QOF is basically a
"GObject-for-Gnucash" plus persistence and query support, but you've
drawn it as basically "GLib+GObject-for-Gnucash" plus the kitchen
sink.  IOW, you've pulled in some things that Gnucash shouldn't expect
to get from libqof, like logging, math, numerics, date functions, and
general utilities.

        Secondly, even if libqof were made to be just the "core" QOF
concepts, I'd still be a bit uncomfortable about its API and its
design.  In order to be comfortable using an external library its API
has to inspire a confidence that says, "Yeah, I can use and live with
that interface, at least until I'm ready to depend on the next
version."  The QOF API just isn't polished enough to inspire that
confidence.

        Regarding design, (and this is less important since, if you
use a library and it works, you care less about _how_ it works) QOF
also doesn't inspire the kind of confidence that says, "Ok, this
design is sound, any flaws are fixable, and the strategy is
maintainable in the long-term."  In particular, there's some noticeable
conceptual overlap between QOF and GObject, but for the duplicated
functionality, the GObject design is really much more complete,
extensible, logical, well-documented, etc.  It would inspire more
confidence if QOF would leave the object-relational and
type-mapping/type-system to GObject (or some other library designed
specifically for that) and concentrated just on offering a querying
and persistence framework.  (BTW, I understand the historical reasons
behind the design, but that doesn't change the current evaluation.)

        Now, I don't have any problem with you (Neil) building,
packaging and distributing an external libqof, or even me personally
developing for it, but I don't think it's good for Gnucash right now
to use an external libqof.  The effect of depending on external libqof
would be to discourage buxfixes and improvements that can now happen
quite easily.  Just to be clear, if some other project want to depend
on an external libqof and some developer makes a libqof available,
fine.  We just can't tie the hands of GnuCash.

        I think the disadvantages of Gnucash using external libqof are
overwhelming, but let's at least ask what are the advantages?  Well, a
user who used external libqof for both gnucash and gnotime would save
a few kb disk-space.  In *theory*, an external libqof would be
maintained by non-gnucash developers, gaining labor efficiency.  But,
in practice, allowing external libqof means gnucash-developers have to
become libqof developers, with additional overhead labor and _reduced_
efficiency.

        Neil, the way I see it, you're riding a fence, and you're
bound to be frustrated and to frustrate others.  I'd recommend
choosing one or the other:

        1) Continue libqof development in gnucash svn, build and
release external stand-alone libraries from this source, even though
GnuCash won't use them externally.

        2) Fork the code from the gnucash qof, develop and release it
independently from Gnucash.  One implication of this is that merges
into gnucash svn's qof should STILL be incremental and reviewable NOT
huge "sync with external QOF version blah".  That really bothers me.
Yes, that means that merges are more difficult, *especially* since
both projects use non-distributed SCM tools.  But hey, that's the way
a fork works.

        I think 1) is preferable, but notice that either way Gnucash
development is unchanged and continues to work (as well as it does at
least :) .

        In any case, just to make things clear: I'm advocating
disabling the option to build Gnucash with external QOF.  The only
reasonable alternative is to stop development in /lib/libqof when
external QOF does a release.  I'm strongly against that alternative.

-chris