Confusion about use of G2

[Chris Shoemaker]

On Sun, Oct 02, 2005 at 08:58:47PM +0100, Neil Williams wrote:
> On Sunday 02 October 2005 7:46 pm, Chris Shoemaker wrote:
> > > |         Now I understand any such policy is merely an ideal whose
> > > | actual application must also consider many practicalities.
> > >
> > > One of which is spinning out QOF.
> >
> > Care to explain that?  I was more thinking about practicalities such
> > as developer time and efficiency.
> 
> 1. Removing scheme/guile from the engine code - an inherent task within 
> spinning out QOF, two sides of the same coin.

Laudable, believe me.  But necessary for G2 release?

> 
> 2. Not to put too fine a point on it, my developer time copying QOF files into 
> GnuCash each time it needs an update! 

Why does G2 always need newest QOF?

> Gnucash is benefitting from wider use 
> of QOF and will benefit much, much more as cashutil develops. I know that 
> probably doesn't matter to you but it does to me.
> 
> 3. In terms of user experience and expectation in G2, QSF exports and QOF 
> merge will provide solutions to real user problems relating to data import, 
> export, mining and customised report generation. 

All these are wonderful, but they are *new*features*.


> The GUI code to get the best 
> out of QSF is not all in place but there is sufficient - particularly with 
> the business features - to make it very useful. Adding similar commands to 
> export accounts and transactions between specified dates into QSF is a small 
> task - it depends on how other things pan out.
> 
> If you limit it to an empty feature-parity then this last fix for the error 
> logging and finishing the fix to the backend load method are the only 
> remaining QOF tasks. The rest of the code is already in place and has been 
> for some weeks.

This backend load method doesn't sound like a broad architectural
change.  Is it?  Does that mean you won't make any more such changes
until G2 is released?
 
> > > I get the same with all the GOffice code and it's dependencies. Then OSX
> > > has horrible problems with the frequent use of -module in the makefiles.
> >
> > You get massive patch breaking due to code churn?!?  What code has
> > been churning under you? Surely not GOG.
> 
> The goffice code in the gnucash tree hasn't necessarily changed, but the 
> dependencies of that code HAS changed, that's why I have several patches for 
> files under lib/goffice to allow it to compile. I'll be looking at using 
> external GOffice libraries soon - should have done it earlier but had to get 
> QOF ready for pre-release.
> 
> > > I wish you'd said something when I started talking about trace changes
> > > on this list. Are these changes compatible with using trace via the
> > > external QOF library?
> >
> > Some are.  Some aren't.
> 
> So what are the benefits of your trace changes? What do they cover?

Easier addition of new logging modules - but your changes are more
extensive than mine.

> 
> > There might be a logical leap here.
> >
> > 1) QOF needs release imminently.  [ Let's take this as a given. ]
> >
> > 2) GC needs to use QOF as external library.
> >     [ I'm not exactly sure how strong a need I would admit, but let's
> > assume this is completely true. ]
> >
> > 3) Therefore, GC needs, in the next G2 release, all these
> > architectural changes to support the new release of QOF.
> >
> > I don't see 3) following from 1) and 2), but feel free to make the
> > case.
> 
> 1. GC needs the backend to be fixed. There is a working fix out-of-tree but it 
> needs to be fitted into GC.

What's broken about current G2 backend?  I only use the xml backend,
so from my perspective it already works well enough in G2 to release.
Am I missing something?

> 2. I anticipate that remaining issues should be small and therefore it is 
> worthwhile seeing if G2 can work with an external QOF once the backend is 
> fixed. I see no point in releasing G2 with an internal QOF library that is 
> maybe 99% identical to 0.6.0. I really do feel that once the backend is 
> fixed, the remaining work is that small. This last patch achieved a massive 
> amount of progress on separating QOF from gnucash. It could (should) have 
> been done a long time ago.
> 
> > Don't assume that everyone knows what you know about the wonderful
> > benefits of QOF.
> 
> My motivation at the moment is simply to avoid duplicate code. Whenever 
> possible, G2 should be allowed to use an external QOF library that will be 
> available before G2 and which contains virtually identical code.

Ah, I think I'm starting to understand.  You want to allow G2 to use
external QOF.  Is there consensus that G2 shouldn't be released until
we've achieved this goal?  I'm asking because I'm fine with a G2
release that uses internal QOF.  In fact, if externalizing QOF is
delaying G2 release, I think that's bad.  What do others think?

> 
> > Please explain why G2 can't be released, with 
> > feature parity with "G1", without architectural improvements.
> 
> The only remaining problem is that in the backend. I expect to be able to fix 
> that in the next two weeks (I'm away most of next week). The current gnc- 
> code is not working properly.
> 
> There are also architectural changes to the makefiles for libraries that use 
> -module for G2 to work on Mac OSX. Those warnings that we all see about 
> linking executables against ... library not beng portable - those warnings 
> bite on OSX and those were not a problem with the 1.8 tree (I think due to 
> the version of gcc available for 1.8). They will, however, halt the build of 
> any G2 package if not fixed.

Yeah, I think this is critical.  I wish my patch breakage were from
things like this being fixed.

> 
> A relatively minor change that I need to be able to test and then implement.
> 
> > Note 
> > that it's not enough to simply explain how great QOF is for GC.  Lots
> > of things are great for GC that won't be in the first release of G2.
> > Why should all these QOF changes?
> 
> 1. To make use of the gnome2 architecture at the level of glib.

But your changes aren't related to dropping a glib1 dep, right?

> 
> 2. To prevent duplicate code - I will do everything I can to allow G2 to go 
> into at least Debian with an external QOF dependency. I have completed the 
> vast majority of that work, I only have a few fixes left to implement. After 
> that, libqof1 will remain API compatible for some time so gnucash can make 
> subsequent releases without problems or synchronisation. It's just that there 
> have been so many changes from QOF 0.5 to QOF 0.6, it's all a little fraught 
> at the moment.

Duplicate QOF is obviously not ideal, but if we worked on
externalizing all the in-tree libraries, G2 would never be released.
We have to draw a line somewhere.

> 
> > > Then there are the changes required to work with cashutil - again these
> > > are architectural changes to libraries and makefiles, as well as the
> > > abstraction of the GUI logic into a library to be shared with cashutil.
> >
> > Again, fine, let's assume cashutil is wonderful.  Do we have to make
> > architectural changes to G2 to work with cashutil in order to achieve
> > feature parity?
> 
> No. cashutil is completely separate, it has helped me fix the backend problem 
> but it's main contribution won't be visible for a time after QOF 0.6 and G2. 
> I could not have started cashutil without the work I've done already for QOF 
> and the new pilot-QOF application.

So these are architectural changes that won't benefit us until far
down the road.  Those types of improvements are very important but I
think they shouldn't have been done in G2.  I hope you'll save these
types of changes for the next developement tree.

> 
> > > I've got a usable undo framework out-of-tree and it will stay there for
> > > now. I'll also be implementing the logic abstraction out-of-tree. I
> > > can't introduce those to the gnucash tree until gnucash itself is closer
> > > to accepting cashutil which in turn requires a completed QOF spinout.
> >
> > [I'm assuming you're thinking post-G2 release here.]
> 
> Yes, principally because cashutil requires large amounts of new or relocated 
> code to implement the logic. That code is nowhere near ready.
> 
> > So you *do* see 
> > a distinction between architectural changes that should wait until
> > after G2 is released and those that are necessary now?  Could you
> > explain what that distinction is?
> 
> 1. QOF 0.6.0 is ready and I want to do what I can to allow gnucash to use it 
> fully.

You essentially mean "externally", right?  I'm skeptical of the
necessity for this in G2, but if you're saying there's not much more
to be done, I'll stop complaining.

-chris

> 2. cashutil is a recent addition and is not ready.
> 3. Undo is simply too large a feature to add in these circumstances. It is 
> still v.new and insufficiently tested.
> 
> -- 
> 
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
> 



> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel