On maandag 16 mei 2011, John Ralls wrote: > On May 16, 2011, at 6:10 AM, Derek Atkins wrote: > > John Ralls <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
