I am developing a desktop application (C++/Qt), which might be roughly represented as consisting of two parts - data-handling part and the GUI.

I want the data-handling part to be extensible with 3rd-party plugins. After thinking over possible strategies (and googling :) ), I've come to the conclusion that probably the optimal way is to use plugins as standalone executables which might be started as separate processes from my main app.

The advantage here is that 3rd-party plugin developers are not restricted to using the same language that I use for the main app (C++) - they might create plugins with whichever language they choose. The only thing they need to know is the protocol of data exchange with the main app (for which I see two alternatives - either using standard pipes to read/write data from/to plugins as child processes, or I might set up local server and then exchange data with plugins via, e.g., HTTP requests).

But then I thought - given this advantage, why can't I remember a single desktop application which uses such strategy? :) Are there drawbacks that I miss? Does anyone know of a desktop app which works with plugins written in entirely different languages?

  • Just want to point out that even with in-process plugins, you don't necessarily force the plugin writer into a specific language (for example, using a c api) – Bwmat Apr 20 '19 at 19:04
  • So, after exploring/trying the possibilities for a month or two, I've ended up with the conclusion that the best strategy for plugin framework, at least in my case, is embedded scripting. I didn't suspect this option before (probably because I'm not well familiar with scripting languages), but it's really the simplest one. It is possible to embed a script engine into your app and provide APIs for e.g. Python or JavaScript. Some scripting languages (e.g., Lua) are very lightweight and were specifically designed for embedding. Writing this for those who also seek extensibility strategies. – Maximko May 30 '19 at 7:57

I can recommend this approach. Of course, there are a couple of potential drawbacks - depending on what you're doing:

  • Performance You'll have to go through serialization, deserialization and IPC. However, you'd have to work with a really high volume of data or a seriously performance-critical application for this to actually matter.

  • Convenience The plug-in developer will have to implement your protocol. While this provides flexibility, it also requires additional work. You could mitigate this somewhat by making your protocol simple, using standard technologies and/or providing a library in a few popular languages.

  • Integration A few applications may want their plug-ins to have very extensive control over the host application's model. Having to go through the abstraction of your protocol might be quite tedious compared to simply getting a pointer to the actual model.

For most applications, I'd say the benefits substantially outweigh the drawbacks.

There is at least one example of such a design that I can think of: the Language Server Protocol. It allows code editors to communicate with editor-independent, language-specific plug-ins that provide features such as syntax-highlighting, auto-complete, etc.

The protocol is supported by various editors (e.g. VS Code, emacs, vim) and many language servers have been written in a variety of different languages.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.