Re: libgnomeoffice* status
- From: Jody Goldberg <jody gnome org>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: Dave Malcolm <david davemalcolm demon co uk>, GNOME Office <gnome-office-list mail gnome org>
- Subject: Re: libgnomeoffice* status
- Date: Sun, 21 Sep 2003 00:41:00 -0400
On Fri, Sep 19, 2003 at 12:44:23PM +0200, Rodrigo Moya wrote:
> On Fri, 2003-09-19 at 12:46, Dave Malcolm wrote:
> > Some questions:
> > (i) I take it that the idea is that I subclass GOfficeService as
> > necessary for my own app-specific plugins?
> >
> I guess the best thing is to share as many service definitions as
> possible. So, if your plugins implement services that are useful to all
> GO apps, we should have the service definition in libgnomeoffice, and
> then you just have to get your plugins to implement those services.
>
> If the services are too specific for your app, then yes, create your own
> GOfficeService-based classes.
I agree that it would be nice to share service types whenever
possible.
> > (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.
> > (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
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]