r20616-20630 (GncOwner)

Phil Longstaff plongstaff at rogers.com
Mon May 16 10:17:38 EDT 2011


Yes.  They were moved there later

 Phil
---------
I used to be a hypochondriac AND a kleptomaniac. So I took something for it.




________________________________
From: John Ralls <jralls at ceridwen.us>
To: Derek Atkins <warlord at mit.edu>
Cc: devel gnucash <gnucash-devel at gnucash.org>
Sent: Mon, May 16, 2011 10:11:07 AM
Subject: Re: r20616-20630 (GncOwner)


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?

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.

Regards,
John Ralls


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


More information about the gnucash-devel mailing list