How does plugin/plugin dependency work?

8
votes

I've a very basic question about the practical operation of software plugin systems. I understand how a simple plugin design works, ie one where a plugin adds to a hosting application. Eg a plugin adds a new filter to a paint program. The host knows it has to call a method called filter which the plugin provides. In this case all plugins are independent.

My question relates to the case when one plugin can use the facilities in another plugin. For example there may be a plugin that provides the ability to plot data while another plugin generates data. If the data generator plugin has never seen the graphing plugin before I assume there is no way for it to know what methods to call in the graphing plugin. I presume that in these cases, the developer of the data generator plugin must have access to a description of the graphing plugin API either in the form of an abstract class or an interface. Is this how plugin dependency operates, ie plugins know explicitly about the Apis that other plugins might have?

I've just built such a plugin system and for plugins to be able to use other plugins I am including in the source code copies of the plugin interfaces each plugin needs to know about. The problem with this approach is that if a new plotting plugin comes along but with a different API, there is no way for the data generator plugin to use it without first being recompiled so that it is aware of the new API. This doesn't seem right to me.

I know this may seem to be a very simple question and have an obvious answer but I've spend hours searching the internet and I've not come across an explicit statement concerning this question.

1
delphiplugins
Marjan's first paragraph answers the bulk of your question. I would, though, strongly advise you to use interfaces rather than abstract classes. Using interfaces will enable plugin authors to use different Delphi versions from you, and even to use different languages if you define your interfaces carefully enough. – David Heffernan
@David - Do you know of any examples of such interface use for plug-in? – Brian Frost
Delphi ToolsAPI is such an example. – David Heffernan
I think the original toolsapi in delphi 1 used abstract classes but then they moved over to interfaces in later versions. – rhody
Keep the ball rolling! Hopefully, rhody make an edit to publish his own implementation of plugins dependency management. The topic is very interesting. – menjaraz

1 Answers

8
votes

If your "new plotting plugin" has a different API from the one your code knows about, there is no alternative but to make your code aware of this API.

If you are in control of all this, including the various plotting plugins, then you c/should specify a standard Plotting API that all plotting plugins need to implement/support. That is about the only way that you can have different providers (plugins) for some task.

A standard "language" is the way to ensure that you can use multiple implementors of an interface (providers of a service). It is also the way that you can have multiple users of the same interface (consumers of a service).

The need/wish for multiple providers of a task and for multiple consumers of a provider is probably what led to the creation of standards such as OAuth, and of protocols such as HTTP, SMTP and the like.