Re: Plugin System

[Jody Goldberg <jody gnome org>]

On Mon, Sep 22, 2003 at 02:22:47PM -0700, Bob Smith wrote:
> On Mon, 2003-09-22 at 03:19, msevior physics unimelb edu au wrote:
> > 
> > An XML description of the plugin, it's location in the menu structure(s)
> > (it might appear in the main menu or one or more context menu's) and/or
> > toolbar structure, it's name and it's tooltip. This all needs to be
> > localizable.
> 
> Hmm... A menu item service. This is something I haven't considered.
> Following the current implementation discussion and the way you would
> like them, you could implement a menu item service and a proxy for it.
> Then store all the information needed for the menu item in the metadata.
> This is a very shareable service type, so maybe we should have this one
> provided stock.

Menu/Toolbar extensions are definitely a fairly shareable service.
I'll advocate we use the new GtkUIManager xml syntax to handle
things and can have a stock implementation based on that in the gtk
specific library.  However, I should note that this is only _one_
potential service.  Just to start getting all of us on the same page
I'll define a few terms and mention some other types.

Plugin == a single blob of code that can be loaded into an
	application.  There can be at most 1 active instance of each
	plugin within an app.  I'm using this simplistic, and
	somewhat restrictive characterization to avoid turning this
	into a component architecture.  Bonobo activation was a huge
	pain because these sorts of things were not terribly clear.

A Service == A interface (likely implemented via glib interfaces)
	that is known to the application.  We might want to support
	plugin defined services if we want to support inter-plugin
	depends
	    eg a pluging written in python would depend on the python
	    loader plugin.

Service Implementations == Plugins (or the main system) can register
	objects that implement various service types.  The plugin
	meta-data will define which implementations are available,
	and which services each implements.

	Banging through gnumeric I've found 3 basic types of
	services
	1) Application extensions
	    These are always loaded (if the plugin is active) and
	    somehow tack them selves onto the app.  They have
	    startup and shutdown methods.
	    eg UI extensions

	2) Objects
	    Implement some new GObject type.
	    eg File I/O, or gnumeric's plot engines

	3) Data
	    Pull in some external data.  Eg the high level
	    predefined plots in gnumeric.

Lets start with this and see if there are missing use cases
then push forward onto plugin discovery and management.  Then finish
up with the probably controversial underbelly of shared service
implementations, classes like GOApp ...