plugin/module architecture proposal for gnucash-1.7

[Bill Gribble]

On Mon, Jun 11, 2001 at 10:00:14PM -0500, Kevin Finn wrote:
>  - 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.

right.  A lot of this will depend on how Guile's module system shakes
out before the guile-1.6 release.... and since our own Rob Browning is
the guile-1.6 release manager, we have a little to say about that :)

>  - 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?

I had assumed that there would be not one but several of these tables,
maybe even several per module, and that their implementation as tables
would be invisible; that is, each module has a function called
"register_foo_handler" and "unregister_foo_handler" which take a
foo_handler as an argument.  This would be more of a policy statement
than an implementation; various modules will want to implement this
stuff in different ways.  I suggested a lookup table because that's
the clearest example that comes to mind.

Exactly what a foo_handler is depends on what "foo" means; i.e. the
HTML subsystem has "register_object_handler", where the handler is a
function that takes a gnc_html widget, a hash table, and other things
needed to build the object.

A pure-Scheme module could add behaviors to other modules that
published wrapped versions of "register_foo_handler" or that defined
them natively as Scheme; for example, "define-report" and
"define-stylesheet" work this way in the current codebase.  The report
and stylesheet tables would be a part of the (gnc report) module, and
(gnc report account-summary) would have to (use-modules (gnc report))
before it could register itself with the report system.

>  - 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.

That was actually one of my motivations :) The gigantic "gnc.gwp" file
bugs me because of its unweildyness and unmaintainability.  Lots of
smaller g-wrap files will make it easier to work more towards complete
coverage of the relevant APIs.

I'm not sure where namespace collisions would be a problem here.  Do
you have an example problem case?

Thanks,
Bill Gribble