Previously we have already touched the technical aspects of creating plugins in Qt. This time we will talk about the theoretical side of the question. Now the question before us is not “How?”, but “Why?”.
Let us briefly recall what a plugin is. A plugin is an optional dynamic library which implements a given interface. This means that an application which uses plugins consists of a core and plugins. These modules are not mandatory. They can be added and removed at will without reassembling the entire project, and have a minimum number of dependencies between them (ideally – do not depend on each other at all). At the same time, anyone who knows the plug-in interface can create their own plug-in for the application without having access to the source codes of the project.
Several pros and cons of using plugins follow from this definition.
Plugins – pros
Popularization of the application
Adding support for plugins to a project and not counting on this plus is quite strange. Third-party extensions are the main driving force behind the growth of your app’s capabilities and popularity in this case.
You create a robust core and a minimal set of quality plugins. You open up the plugin interface. And if all goes well, you get a lot of add-ons developed by other people. Many well-known IDEs, graphics editors, and other feature-rich applications go this way.
Going to an open-source for an entire project doesn’t provide the same benefits. If the application is open-source, but does not have easy ways to add extensions, users will either settle for the out-of-the-box version or choose a more “flexible” solution. A similar situation is true for the dwm graphical shell. The description of the process of installing “extensions” for dwm (or more precisely, patches) turned out to be so complicated that it turned into a full-fledged article.
Easy update
A modular application consisting of plugins is much easier to update on the user side than a monolithic one. Technically, it comes down to simply adding or replacing one or more extension library files.
Since the plugins have little dependency on each other, any user can put together an application to his own taste, as from a constructor. In doing so, he gets only what he needs. Such a constructor application is almost impossible to implement without using plugins – you would have to have thousands of assemblies with all possible combinations of feature sets (or get an inconvenient patch system like in dwm).
Plugins – disadvantages
Higher complexity of implementation
The more flexible a system is, the harder it is to implement and maintain it. And this is true for all the stages of development – from designing to coding.
The task is really quite difficult. You can’t do without compromises. The difficulty is this: how to choose a plugin interface that simultaneously reveals everything you need while hiding everything else. So we move seamlessly to the next disadvantage.
Security issues
If you don’t limit plugins’ freedom of action, you can run into security problems. What plugins do is the responsibility of the developer and the application core designer. One must always keep in mind that an intruder can slip the user his own plugin under the guise of a “good” plugin. If the plugin is allowed to do anything, anything can happen, depending on the authorization level of the user who is running the application.
To solve this problem, you need to ensure that the privileges with which the plugin will work are lowered.
It is handy to take advantage of programming language security constructs. A good example is the Java language, which boasts many systems and levels of security.
Another option is to develop or use for plugins a special language with more limited features than the one in which the kernel is written (for example, in Qt in C++ you can look at QtScript). A real example of a successful use of this approach is the text editor Vim. It is itself written in C, but there is a special language Vim Script for creating extensions.
If you are extremely serious about the reputation of your product, you can go even further, and engage in rejection of “bad” plugins. Extension developers must pass a quality check, without which their plug-in will not be included in the official database. A similar decision is made in Apple’s App Store.
Conclusions
We can now give an answer to the next question: “When and what to put in plugins”. If you plan to update your application frequently, give your users freedom to choose the necessary set of features, make it relatively easy to add modules from third-party developers, then plugins are your choice.
But don’t forget that full-fledged plugin support is a big responsibility. You should worry in advance about the versatility, reliability and security of the plugin interface. If you are not too interested in the above benefits, it is much easier to limit yourself to usual dynamic (or static) libraries, which will obviously be linked in the process of building the project. In this way, you will simplify your task and significantly reduce the amount of work.