I'm starting a hobby project and I'm in the middle of designing its architecture. I would like to make my program plugin-based (never done anything like that before), to make it extensible. Now I'm trying to grasp how such an architecture is created conceptually.
Now, this wikipedia article about Plugins says that the host application is supposed to provide a protocol service (among other things) to establish how data is exchanged with the plugin.
I don't really understand this tidbit, what does that mean? What kind of data actually needs to be exchanged?
EDIT: Just to be clear, I'm not looking for implementation specifics, but for a clear explanation of the mechanism, that the wikipedia article presents. As it stands now, I have no idea what the purpose of a protocol in a plugin-based application is.
I figured, the plugin could just fetch relevant data from outside the application on its own and present it to the user, without directly involving the application. What would be the purpose of establishing a protocol for data exchange?
It's a desktop application, which will be written mainly in Java, thus object-oriented. The application at its core mainly provides an interface for plugins to register itself in the application and a plugin-manager, which interacts with the plugin.
Best Answer
In my view, plugins are sharing the same address space (& process) as the receiving application and involve dynamic linking.
In Linux parlance, I think that a plugin is a dynamically loaded shared object which is dlopen-ed by the application.
Then the application has to define what dlsym-ed symbols are expected by the application in the plugin, and how they interact with (i.e. how they are called by) the application.
A concrete exemple is given by Gcc plugins (I'm working on MELT, a high-level domain specific language to extend GCC, implemented as a [meta-] plugin); as the document explains, it define some set of conventions that you would call a "protocol service"
Added:
So the plugin protocol is the set of conventions (and associated API and names) defining how the plugin is installed, and which plugin's functions (and names) are expected, in what order and conditions they are invoked by the application, and which application data and API the plugin can access (and modify).