plugins

[John Ralls]

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