Re: libgnomeoffice* status

[Rodrigo Moya <rodrigo gnome-db org>]

On Fri, 2003-09-19 at 12:46, Dave Malcolm wrote:
> On Thu, 2003-09-18 at 11:13, Rodrigo Moya wrote:
> > Hi
> > 
> > Ok, so here's the current status of the gnome-office module:
> > 
> > * libgnomeoffice: non-UI stuff, currently contains:
> > 	- go-plugin-loader: class for client apps to load plugins
> > 	- go-plugin: base class to be implemented by plugins
> > 	- go-service: base class for services (each plugin implements
> > 	  'n' services)
> > 	- go-service-data: data acquisition service (SELECT .. FROM)
> > 	- go-service-file-io: services for file i/o operations
> > 	- go-service-function-group: service that implements a
> > 	  group of callable functions
> > 	- go-service-script-engine: scripting service
> > 
> > * libgnomeofficeui: UI-stuff
> > 	- go-plugin-manager-dialog: this is just the beginning of
> > 	  a dialog for managing the plugins, similar to the one in
> > 	  Gnumeric, but to be shared by all apps. I didnt work too
> > 	  much on it because I prefered to wait post-1.0.
> > 
> > * plugins: built-in plugins
> > 	- database: contains an implementation of the data service,
> > 	  based on libgda
> > 	- scripting: will contain implementations of the scripting
> > 	  service for various languages. Right now, there is basic
> > 	  support for Mono.
> > 
> > So, what are the thoughts on this and on new things to be added? As Jody
> > said, I think it's better to see case by case when the issue arises,
> > but, for the plugin system, we are going to have to share a lot of code,
> > given that abiword and gnumeric and mergeant already have, each one,
> > their own plugin system. So it is the most important thing right now,
> > IMO.
> > 
> 
> 
> > So, do we go on on sharing the plugin system?
> 
> This code looks useful to Conglomerate, and I'm going to have a look at
> using it.  Currently our plugin system is a complete fake; everything is
> simply linked in, but done using service registration hooks.  The "go"
> system seems to be analagous to what I had in mind.
> 
cool

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

> (ii) Are we looking to share plugins themselves, as well as the plugin
> system?  i.e. 
>
yes, that's the idea

> 	(a) there are GOfficeService subclasses that are "publicly" available
> as part of the system (such as the examples listed above), and
>
yes, as I said above

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

> (iii)  Should I add the gnome-office module as an external dependency,
> or should I create a cut-n-paste code subdirectory within my source
> tree, and synchronise on a regular basis?
>
I guess the best thing is for all GO apps to depend on it externally.

> (iv) Similarly, should I add libgsf as an external dependency, or
> internally as a cut-n-paste dependency?
> 
external also

cheers