I hate to spoil the fun but I think maintaining a plugin that needs to be compiled against new versions of distro libs and KDE itself will become a headache very quickly…
I’d strongly prefer writing plugins in an embedded scripting language, even though it’s more work for the host program author to provide that.
Programs and plug-ins written in dynamic/scripting languages also rot. It is just not visible at the first sight and they crash during runtime instead of compile time.
Doing something actually loosely-coupled is much more difficult than just pretend it and conceal the dependencies.
They certainly do rot but when a C++ program exposes an API via an embedded interpreter, the most likely source of incompatibilities is the API that the host program maintainers chose to expose. As long as they don’t intentionally change it in incompatible ways, old plugins will be fine across all OSes.
Compiled plugins will immediately need to be built for all systems where the author wants to use them and almost invariably need to be rebuilt on distro upgrades.
Using an embedded scripting language is not a magical solution to everything but maintaining a stable scripting API is a lot easier than maintaining a stable ABI — most of the time you can keep it stable simply by not messing with it too much.
Always cool to see people writing plugins to KDE apps!
Shared this with some KDE devs as well.
I hate to spoil the fun but I think maintaining a plugin that needs to be compiled against new versions of distro libs and KDE itself will become a headache very quickly…
I’d strongly prefer writing plugins in an embedded scripting language, even though it’s more work for the host program author to provide that.
scripting language != stable API
Programs and plug-ins written in dynamic/scripting languages also rot. It is just not visible at the first sight and they crash during runtime instead of compile time.
Doing something actually loosely-coupled is much more difficult than just pretend it and conceal the dependencies.
Well-defined and stable interface is the key.
They certainly do rot but when a C++ program exposes an API via an embedded interpreter, the most likely source of incompatibilities is the API that the host program maintainers chose to expose. As long as they don’t intentionally change it in incompatible ways, old plugins will be fine across all OSes.
Compiled plugins will immediately need to be built for all systems where the author wants to use them and almost invariably need to be rebuilt on distro upgrades.
Using an embedded scripting language is not a magical solution to everything but maintaining a stable scripting API is a lot easier than maintaining a stable ABI — most of the time you can keep it stable simply by not messing with it too much.
I tried using kmail again after many years, but somehow I could never get warm with it. Still great to see that it is still alive and well.