Re: Plugin System

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2003-09-08 at 03:41, Bob Smith wrote:
> 
> >     need to do this at start up.  To date we've made the simplifying
> 
> Thats something that needs to be addressed. Although, you could make the
> argument that you too are discovering the plugins on startup. You just
> only have one way of doing that. 
> 
hmm, sorry if it's obvious, but why do we need more than one way to
activate plugins? If we need to support several directories, we can have
a system-wide gnome-office.xml file that contains the list of
directories to search for plugins.

> >     reason for using that model instead of a pango-querymodules
> >     approach.
> 
> There's a few ways to do this:
> 1. Have a binary file that's all the plugin information boiled down into
> a nice fast single file that the plugin system could read. That would
> make startup the fastest. Plugins would need to be registered with the
> file when installed.
>
hmm, this sounds good. In libgda, we just use that way, instead of the
.xml file. We search in a given directory for .so files, and try to call
a set of defined functions that gives us enough information about the
plugin.

I think this can be much better than accompanying the plugin with the
xml file.

> > 
> > > Notes:
> > > 1. Proxies. A lot of programs wont need proxy objects. Let the application provide them.
> > 
> > What's a proxy ?
> 
> An object that acts like a service but is just a wrapper around it so
> you can delay the loading of a plugin until absolutely necessary.
> 
hmm, I guess this separation is already made with the Plugin->Service(s)
separation. Also, using a libgda-like way, there is no need for the
proxy, AFAICS.

> > 
> > > One main GObject that deals with these features:
> > > 1. State property.
> > > 2. Add directory. State becomes PROCESSING. Idle callback to update metadata.
> > > 3. Remove directory. State becomes PROCESSING. Remove metadata. Idle callback to unload relevent plugins.
> > > 4. A function to get a list of directories.
> > Why are we talking about directories at this level ?  If we're truly
> > going to abstract discovery isn't 'xml files in directories' an
> > implementation detail of the current form ?
> 
> This allows the user of the application to give a hint to discovery
> objects where to look for plugins. Discovery objects are free to look
> elsewhere (for example, a web server). Ex, Three different plugin
> discovery mechanisms. One for R files, One for Mono and one for XML
> described plugins. They all might want to look in
> "/usr/share/gnumeric/plugins" and "/home/foo/.gnumeric/.plugins". A user
> might want to look for plugins in "/shared/gnumeric/plugins" too. This
> would inform all the discovery objects to look for their plugins in that
> directory too.
> 
I think we can just have a set of default directories to look into
($prefix/lib.../plugins, and ~/.gnome-office/plugins, for instance),
and, apart from the system-wide XML config file (where you can specify
new directories), and a way for client apps to add, at run time, other
directories, we are set.

> > 
> > Why talk of idle handlers ?
> > 
> 
> So if things take too long to load, the GUI can be refreshed while it
> processes without the need of threads.
> 
idle handlers give a lot of problems, when using many parallel calls.
The problem with using idle handlers is that apps, when calling the
plugins, will think it's synchronous, which it isnt, since you can,
while making the call, get a signal callback called, which breaks the
"supposed synchronicity".

> > > 1. A service almost never can be shared between apps, so
> > > information about them (Like metadata description, parsers, and
> > > display widgets) should usually be implemented in the application
> > > itself rather then a generic library.
> > 
> > Agreed.  Although I would add the notion that a plugin should be
> > able to add service types for other plugins to implement.
> >  
> 
yes, right, this is a great idea.

> > 
> > Service 	: An interface specification.
> 
> Yes.
> 
> > ServiceImpl	: A factory that produces objects supporting a Service
> 
I find this redundant. THat's exactly what the Plugin class does.

> This is a detail. My plugins don't need factories, they just need one
> instance of a service. If the instance of a service supports spawning of
> more objects like a factory, thats up to the service itself to decide.
> Maybe we should say, ServiceInstance.
> 
> > Plugin  : A blob that that contains implementations of services
> 
> Taking ServiceInstance from above,
> Plugin: A blob that contains instances of services.
> 
there can be a service which is for registering other service types, and
the Plugin class contains both these and the service implementations.

> > - Define plugins on a per application basis.  Sharing them seems
> >   like a very rare use case (?example?).
> 
the data service is the best example so far. Since both gnumeric and abi
use libgda to get data...

> Agreed. I've thought about this some more and still couldn't figure out
> a good example of when they really would need to be shared. The way I
> described things in the doc though, it wouldn't be impossible to share
> plugins. You would just add a directory to the list that contains the
> shared plugins in each app sharing them.
> 
I think we can just have each app query the plugin loader for the
plugins that implement the services it understands. Thus, the services
not supported/understood by the app wont ever show up in the plugins
manager dialog, for instance. I dont think we have to complicate things
more.

IIRC (dont have the GO sources here), there is code to do that "get me
services of this type". And if there isnt, we just need to add it.

cheers