Re: Plugin System

[Rodrigo Moya <rodrigo gnome-db org>]

On Mon, 2003-09-22 at 00:23, Bob Smith wrote:
> On Sat, 2003-09-20 at 14:40, Rodrigo Moya wrote:
> > 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. 
> > > 
> 
> Jody and I spent a significant amount of time figuring out a common set
> of terms so we could describe what we need. Some of this email covers
> that. I don't know if your following paragraph asks me about a loader or
> a discoverer. Multiple discovery types would allow for things like
> storing the list of plugins on a server or storing plugin metadata in a
> .net dll.
> 
oh, sorry, I didn't get the point of having this. I know have
understood.

> > 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.
> > 
> 
> Talking to Jody, the current way of loading up .so files to get the
> metadata is not acceptable to the Gnumeric folks.
> 
ok

> The binary metadata cache idea I really like. The only thing I don't
> like is the requirement for a user to manually register plugins. The
> plugin system could take care of registering new plugins on startup at a
> slight first time load up hit. Its something I want, but could live
> without.
> 
what do you mean by 'manually register'?

> > > > 
> > > > > 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.
> > 
> 
> Proxy's are used in Gnumeric. Since most other people don't need it, we
> can just leave the code in Gnumeric. We shouldn't concern ourselves with
> them, other then realize that some people might want to implement them
> on top of GO.
> 
hmm, it makes sense anyway to have an abstract class that implements the
proxy, if possible, and leave its usage as an implementation detail to
each service, right?

> > > > 
> > > > > 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.
> > 
> 
> Jody and my discussion lead us to believe that plugins were not going to
> be shared. If they always are to be shared, then your right, there's not
> much need for changing the directories.
> 
as I said in other mail, I think there are a few plugins that ought to
be shared. Of course, most will not, as they are going to be specific to
each app, but some like the scripting engine and the data acquisition
services make a lot of sense as shared.

> > > > - 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...
> > 
> 
> Ok. This is the first good example I've seen. You've just convinced me
> that sharing plugins is in fact something that should be supported. :)
> 
and the scripting engine :-)

> > > 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.
> > 
> 
> Yeah. Something like, Give me a list of services that are of type "foo"
> would work.
> 
yes

cheers