Should GnuCash use an external QOF library?

[Neil Williams]

On Wednesday 11 January 2006 4:23 pm, you wrote:
>         Should GnuCash use an external QOF library?

At a packaging level:
Wherever QOF is available, yes.
Wherever QOF can be made available, also yes.

At development level, I'm reasonably happy with a copy of QOF copied into 
gnucash prior to a QOF release.

>         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,

Drop the gnucash. QOF is not part of gnucash, it does not have any direct 
relation to the gnucash codebase anymore.

The breadth of QOF is just fine. It should not get any bigger (by using 
modules I can retain much the same installed size which is imperative for 
embedded systems). It cannot get any smaller without impinging on existing 
applications.

Besides, I didn't decide what goes into QOF, that decision was made by Derek, 
Linas and others. I'm quite happy with it. The files I removed from 
src/engine were only the ones already released separately by Linas.

> 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.

Logging: Required for pilot-qof and cashutil.
Math: Gnotime, gpe, cashutil
Numerics: Pilot-qof, GPE, cashutil.
Date: pilot-qof, gnotime, GPE.
general: All the above.

I will be reviewing gnc-date.c at the time that it gets renamed qofdate.c and 
I'll discuss here (particularly with David) what to do with functions that we 
all know don't really belong in QOF.

You cannot seriously expect to help develop libqof if you are only prepared to 
discuss it from a gnucash perspective. QOF is a lot more than it's limited 
use in gnucash.

>         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.

Hence my file replacement and function convention changes during the life of 
libqof1. I can't help what existed before I started on QOF. All I can do is 
smooth out the API whilst retaining binary compatibility until such time as 
libqof2 is available.

>         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.

Quite the opposite. QOF in wider, earlier usage has already benefitted gnucash 
by feeding bugfixes from real installations back into the lib/libqof code.

Using QOF externally in development isn't the issue, anyway. Just coordinate 
with me when you work in lib/libqof.

What I ask is:
1. Coordinate with me before committing changes to lib/libqof - unless the 
	changes are a CRITICAL bug. Even then, let me know *urgently*.
2. Always keep in mind that there is as much of QOF outside gnucash as there
	ever could be inside and don't make changes that are gnucash-specific.
	(i.e. do not use gnucash defined macros or build structures.) This is
	imperative in an embedded environment.
3. Listen in on QOF-devel just to get notice of latest developments and 
	releases.
4. Do nothing to increase or modify the existing dependencies of QOF.

>         I think the disadvantages of Gnucash using external libqof are

inconsequential at a packaging level.

> 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.

QOF is going to be updated far more regularly than gnucash, that's beneficial.

QOF is also due to inherit some very useful backends that will not necessarily 
make it into gnucash svn.

> 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.

? Nobody from here has to join me in QOF development, I don't see the problem 
or any additional overhead.

No gnucash developer needs to be diverted or become a libqof developer. I'll 
do all that - as long as the gnucash developers respect the division.

>         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.

Impossible. libqof cannot be developed in gnucash svn. It has outgrown gnucash 
and is going into places that gnucash simply cannot follow. Completely 
inappropriate.

It's hardly suprising that I've still got some cashutil code outside gnucash 
svn. I may yet take cashutil to a separate repository - especially as nobody 
here appears to have even looked at the branch.

>         2) Fork the code from the gnucash qof, develop and release it
> independently from Gnucash.

It is already developed and released independently from gnucash. I don't see 
the need or benefit for a clean fork, it's just wasting even more effort.

Is it really that hard for a free software community to actually SHARE?

I'm willing to keep gnucash updated with the latest QOF code but I will not 
make duplicate commits for every single change. Neither can I use gnucash svn 
for QOF development, it flies in the face of everything I want to do in QOF. 
The best I can do is update lib/libqof prior to each QOF release.

> 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.

I'm not going to start committing the same change to two trees every time! 
That's a complete non-starter. No matter how much it may bother you, it ain't 
going to happen!

>         In any case, just to make things clear: I'm advocating
> disabling the option to build Gnucash with external QOF. 

Absolutely bonkers.

Do you want me to provide a patch that re-enables it for sensible packaging?

I only ever build gnucash with internal QOF prior to a QOF release.

> The only 
> reasonable alternative is to stop development in /lib/libqof when
> external QOF does a release.  I'm strongly against that alternative.

There IS NO development in lib/libqof (that's why it's no longer under src/).

QOF development happens at SF, it is discussed via QOF-devel and released 
early and often. 

What happens in gnucash svn merely supports the SF development.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060111/a4df00a3/attachment.bin