On May 15, 2011, at 12:04 PM, Christian Stimming wrote: > Am Sonntag, 15. Mai 2011 schrieb John Ralls: > >> 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. > > Sounds very good. I'm all in :-) > >> 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. > > Are you asking whether gnucash should contain any of its functions as plugin > vs. no plugins at all? I agree (and I have stated before) that most of the > loadable modules of gnucash shouldn't be modules, but should instead belong > into one big binary and that's it. I have stated a similar goal for the > cutecash experiment. > > However, after thinking about this again, one particular use case for plugins > is still around: Unusual dependencies from code parts that are interesting > only to a subset of the users. Specifically, the aqbanking code part is > interesting only to a small subset of users, and it requires a whole lot of > other dependencies (aqbanking, gwenhywfar and various sub-libraries of > those). > Having gnucash's aqbanking module still around as a loadable module means the > packaging can more this into a separate package, so that users who don't want > the online banking features also don't need its dependencies. > > Again, I'm all in for throwing out most of the current loadable modules. But > in some use cases they are still useful.
Hmm. I can see your point, but isn't there a lot of import-export functionality wrapped up in aqbanking? OTOH, if we could do a good plugin API, maybe people would come forward with more import/export plugins. Conversely, HCBI users wouldn't need to install the libofx plugin. The use-case extends to backends, too. So we agree that it would be nice to have. That doesn't answer the question about whether it's worth the extra complexity. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
