Re: libgnomeoffice* status

[Rodrigo Moya <rodrigo gnome-db org>]

On Sun, 2003-09-21 at 06:41, Jody Goldberg wrote:
> 
> > > (ii) Are we looking to share plugins themselves, as well as the plugin
> > > system?  i.e. 
> > >
> > yes, that's the idea
> 
> That does not seem feasible and is one of the limitations of the
> system you've got in gnome-office that I've been meaning to talk to
> you about.
> 
> My assumption is that a pluing is going to be interfacing with its
> parent app and extending it in some way.   It would be nice if the
> _interface_ (aka service) is shared, but the actual implementations ?
> That does not seem commonly feasible.
> 
well, most plugins are going to be specific (along with their service
types), but I can see a few that can be really useful if shared:

* scripting engine
* data acquisition

> > > 	(b) there are plugins that exist in one shared place to be locatable by
> > > all Gnome Office apps, that provide instances of those services.  Could
> > > lead us to DLL hell...
> > >
> > DLL hell? why? We can just have versioned directories for the plugins,
> > as Gnumeric does, for instance.
> 
> Providing a management framework for the plugins is core
> functionality for the plugin system.  In addition to the current
> framework we need to support
>     - per 'group' (multiple group configurable)
>     - per user
>     - app wide 
>     - per app plugins
> 
hmm, what about then if we have a set of predefined directories to
search for. That is, for system wide:

	$prefix/lib/gnome-office/plugins/groups/group1
	""                            ""/applications/app1
	~/.gnome-office/plugins

the plugin loader could just look in those directories for .so files (or
the .xml files, if we continue going that route).

Or does it seem too complicated?

> In addition we need a strong versioning capability.  To date I've
> enforced a strict seperation in every version of gnumeric.  That is
> potentially to granular for use defined plugins where a user is not
> going to want to link/move their plugins for a minor (non-abi
> changing) release.
>
then we maybe need a version interface in the Plugin class. That is, a
get_lower/_higher_version method.

cheers