r20616-20630 (GncOwner)

Geert Janssens janssens-geert at telenet.be
Tue May 17 04:29:35 EDT 2011


On maandag 16 mei 2011, John Ralls wrote:
> On May 16, 2011, at 6:10 AM, Derek Atkins wrote:
> > John Ralls <jralls at ceridwen.us> writes:
> >> 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.
> > 
> > Technically the business features were designed to be a plugin.  When I
> > originally worked on that code a decade ago my idea was that packagers
> > could build a "gnucash" app and then supply a secondary
> > "gnucash-business" plugin that would supply all the business code, GUIs,
> > etc.   Obviously that never happened, but that WAS the original design.
> 
> Then why are the data objects in src/engine? Did they get moved there
> later?
> 
Christian moved them into the engine because both the python interface and 
cutecash would loose the saved business data when manipulating a datafile that 
had such data.

> Regardless, is there a good reason to keep (or restore) that architecture?
> It fails the test Christian advocated for aqbanking, because the business
> stuff has no special dependencies. It's also difficult to separate the
> data objects into an optional module and maintain referential integrity
> across the module interface.
> 
I understand Derek's original intention to create a business pluging, but in 
practice I see more drawbacks than advantages in keeping the business features 
in a separate module. There has never been a distribution that created a 
business-free GnuCash build with a separate gnucash-business module. That 
would risk data loss as I explained above.

Geert


More information about the gnucash-devel mailing list