plugin/module architecture proposal for gnucash-1.7

[Kevin Finn]

Bill Gribble wrote:
> 
> Well, now that the 1.6 release has happened, it's time to start
> looking forward to the 1.7 series :) This is a proposal that I have
> been wanting to get off my chest for a while.
> 
> ...
> 
> 2. New functionality can be added as modules that require only the
> installation of a new module rather than an upgrade of the whole
> system.  Module versioning and version dependencies that track module
> APIs will prevent skew.
> 
> ...
> 
> What do you guys think?  Specific thoughts/desires about how it should
> be done?

     It sounds like an idea whose time has come.  A couple questions:

 - I'm a little nervous about version skew, having recently worked on a
project in RL that was transitioning from a monolithic product into
separate modules with mixed success.  I think a lot will depend on how
general the module interfaces can be - the less is known about other
modules, the easier to deal with skew if it occurs.

 - is the "function table" located in the scheme layer or the C layer? 
Would a pure-scheme module (say, something that just generates reports
at a terminal) still need a C lib to hook up to the function table?

 - Will each module provide its own g-wrappers, I assume?  Maybe there
needs to be a mechanism or a policy to avoid collisions in that
namespace.


-- 

Kevin Finn
kevinfinn@mediaone.net