Future GnuCash plans (was: Re: r20616-20630 (GncOwner))

[Geert Janssens]

On zondag 15 mei 2011, John Ralls wrote:
> On May 14, 2011, at 4:33 PM, Phil Longstaff wrote:
> > On Thu, 2011-05-12 at 13:49 -0400, John Ralls wrote:
> >> Geert, I was actually thinking from the data model view rather than the
> >> accounting view, but ideally the data model closely reflects the
> >> problem domain, so they're not dissimilar.
> > 
> > [OpenERP - deleted]
> > 
> >> But more broadly, Gnucash is supposed to be an object-oriented design,
> >> so that all of the common elements are provided by a superclass and
> >> any additional specializations (like the pointer to a shipping address
> >> for a customer) are provided by a subclass. (That single
> >> characteristic is the fundamental flaw of the KVP design: Because KVP
> >> data are added to objects outside of the class interface, inheritance
> >> and polymorphism are broken.) The goal of the transactional
> >> refactoring is that the GUI will be able to request from the backend
> >> only the objects it needs to display, to lock only the objects it is
> >> editing, to commit the changed edits as a logically atomic commit --
> >> and to have the whole edit atomically rolled back if any part of the
> >> commit fails. In order for that to work, objects must have control
> >> over all of their member data and be able to serialize it to a
> >> standard interface that an arbitrary backend can store and retrieve.
> >> That was the original design goal stated for QO!  F, BTW, but
> >> gnucash's implementation of QOF has destroyed that ability and
> >> gnucash's use of QOF is inconsistent.
> > 
> > [ there are a bunch of GUIs - deleted ]
> > 
> >> Those two goals motivate my refactoring plan: Make everything in QOF
> >> into a class hierarchy with separation of classes by functional and
> >> data responsibility and all in the same class system (meaning GSEALED
> >> GObject, C++, or Python -- each  of which has advantages, so which one
> >> we use is open for discussion, and that discussion can be put off
> >> until we have complete unit test coverage in QOF), then refactor
> >> Engine, Business Core, and Backend into derived classes from the QOF
> >> superclasses. That's the model part of MVC. After that (or in parallel
> >> if someone else decides to work on it) we need to ensure that all of
> >> the combining of those model objects for presentation to the user and
> >> for handling edits (For example, posting an invoice will need to read
> >> objects of the Customer, Invoice, Transaction, Split, Account, and
> >> Commodity classes, with a write lock on Invoice, Transaction, and
> >> Splits) is handled by another set of classes, so that the GUI and API
> >> can concern themselves only !  with user interaction.
> > 
> > This all sounds great and I'm wondering what the steps are.  One
> > original idea behind KVP is that modules can be added to gnucash and can
> > associate data with the core objects.  An example is a US tax data
> > module which associates an account with a line on a tax form.  Should
> > this tax line become part of the Account record in the db?  Might be OK
> > for US users, but what if a user from a different country needs more
> > information or different information.  Do we want Account, and
> > USTaxAccount and OtherCountryTaxAccount derived from it?  What about
> > other relationship types?
> > 
> > I think it would not be difficult to pull the info currently in slots
> > out of them and into better data structures which have their own tables.
> > They could be attached to the main core objects so that they load/save
> > at the same time but would be independent and in their own tables.  Does
> > this idea help with your refactoring?
> 
> The steps I have in mind are:
> 1. Get complete test coverage for QOF, Engine, Business Core, and Backend
> 2. Rewrite those libraries into a single, coherent class system (we'll
> discuss which one when the test-writing gets close to being done) 3.
> Refactor as necessary to get a good class hierarchy that reflects our
> acccounting model. This is the hard part, because we very likely keep
> different models in our heads, and we're going to have to work out how to
> express those models to each other and work out a common model that we all
> agree on, then document it so that we can refer to it as we refactor the
> code. This refactoring is very likely to involve moving parts of classes
> around, which is the reason for step 2: That's a real PITA if the classes
> aren't all written in the same "language".
> 
This seems like a good plan to me. A huge one also. From how I understand it, 
this plan is close to a complete rewrite of GnuCash' core. Just correct me if 
I'm wrong.

> There's more than one way to extend an object....
I have no particular opinion on how this is done as I lack experience in that 
area. So I'll agree with whatever the others decide here.

> I'm not at all sure that the plugin architecture gets us anything in return
> for the added complexity, though. AFAIK there aren't any plugins. The
> various libraries in Gnucash proper that are dloaded instead of being
> dynamically linked sure doesn't get us anything except longer load times
> and missed optimization opportunities.
> 
I fully agree with Christian's opinion here (we discussed this in the past on 
the list). Plugins could be useful for corner cases, but not for core 
functionality. So we could keep the concept of a plugin, but in my opinion it 
needs work. The current implementation for example prevents good integration 
between the import and business features. Simple things like marking an 
invoice paid (business plugin) by a payment on a bank statement (import 
plugin) is not possible.

Geert