On Wed, 2003-09-24 at 00:15, Martin Sevior wrote: > On Wed, 2003-09-24 at 15:10, Bob Smith wrote: > > > 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? > > I think it makes sense to have common scheme for the XML description of > the plugin. > > My idea is that for every plugin.so, there also exists a plugin.xml. > Upon startup every plugin.xml discovered in the appropriate directory is > parsed. It's used to create the menu items/toolbars and or information > that a particular service exists. Plugins do not need to create menu > items or toolbars and the XML description should allow this. > This is the way its done in Gnumeric right now. Right now this is one of the methods being discussed. Another involves a plugable system. So say, shared lib plugins use an xml file for the description, mono .net dlls are self describing, so the data is read directly out, etc. The data would be cached in a way that would make it as fast as possible to read so that if no new plugins were added, nothing needs to be parsed. > Thinking from the AbiWord experience again plugins provide either an > extra feature accessible from one or more menus or toolbars or they > allow additional file formats to be loaded and saved. > > The XML format should specify whether plugin should be immediately > loaded or whether it can be delayed till later. > > In the case of additional menu items, the plugin need only be loaded if > the user clicks on the menu item. The XML file contains the text and > icons needed for menu/toolbar. > > In the case of document exporters, the plugin need only be loaded if the > user asks to export to that format. The XML file contains the filter > type available for export (so it appears as an option to the user). > > In the case of importers, we may only need to load the "importer > sniffer" to determine if the document presented matches the importer. > > I think we can come up with a single XML format that is general enough > for all our uses without placing extra burden on developers to > understand things they do not need to. Having a single format will help > translators and hackers moving between the different applications. > We're going to support ghost services. It works just like the service it shadows but is a stub. The first time you call a function on it, it loads up the real plugin and makes the call. When you try to get an instance of a service, you can ask for a real or a ghost version. I think this will give you enough flexibility to do what you need, correct? Bob > Martin -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part