I've been rolling this over and over in my mind. I can find very few concrete examples of shared plugins. What abi wants is a plugin to provide data base services to abi. This code is abi dependent. If it uses libgda or odbc or whatever, thats a shared library. Making a generic data base plugin would be on par with rewriting odbc or libgda as a plugin. Now, the one good example is a menu item service. Although, the service type would be sharable, a service of type "menu item" would not be easily sharable. It may be shared if its as simple as "shell to home dir", but in most cases, it will want to hook up into the application its embedded into either directly, or through other services the plugin provides. So, I believe menu item sharing is good enough to justify a global shared plugin default. One recent service idea was configuration widget for a service. This too is tied to another service which in all likelihood is tied to the app as well. This service type should be provided stock, but these aren't really sharable either. Rodrigo mentioned scripting plugins. Having embeded a lot of languages into my apps over time, I tend to agree with Jody. The scripting engine is an insignificant part of code. Unless I can see good evidence that you can do most of the stuff you want from the accessibility api, this is not enough to make me believe that the plugin library should be oriented around a global plugin dir. The one and only plugin type I think could and should be shared is a plugin that provides a loader service. (And a description service if that route is taken). This is basically a plugin for the plugin system. These may be heavily tied to the scripting plugins though. So, maybe scripting plugins should be made plugin system plugins and global in nature and provide a second, application spacific plugin for binding the app to the language. So, unless I hear a better argument, the design should assume that plugins are app specific. If you want shared functionality, it should be implemented as a shared library, and used by your plugin. Also, there may be plugins that are used by the plugin system to extend itself. These will be global in nature. Comments? Bob On Mon, 2003-09-22 at 18:20, Jody Goldberg wrote: > On Tue, Sep 23, 2003 at 11:40:54AM +1000, Martin Sevior wrote: > > On Tue, 2003-09-23 at 08:19, Bob Smith wrote: > > > On Sat, 2003-09-20 at 14:40, Rodrigo Moya wrote: > > > > > > Been thinking about this some more. Why does this need to be implemented > > > as a plugin? The way each app uses the data source is different. So, > > > that code is app specific so it cant be shared. > > > > libgda is not available on Windows. By using a plugin we can provide > > GNOME users extra functionality without having to port libgda to windows > > and without a huge pile of #ifdefs inside abiword. > > I agree with Bob on this. However, that view does not preclude the > use case Martin is suggesting. It makes perfect sense to put the > abiword use of libgda into a plugin. The question is whether or not > that code is so general that it can actually live in a 'stock' > plugin offered by libgoffice, and that seems implausible to me. > > Every plugin we've got in gnumeric is specific to gnumeric, even the > language bindings. As such I'll assume that the primary use case > will be for app specific plugins, rather than goffice wide shared > plugins. -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part