@algernon recently wrote about [Managing core and contributed Kaleidoscope plugins](his progress) on categorizing parts of the firmware.
It seems he is currently working on a grouping/categorization/modularization/git-submodulification of the existing parts of the firmware.
When I read his ideas about categories and the list of projects, it occurred to me that some of these projects, core and third party modules are not plugins in a strict sense.
Up to now everybody uses the term plugin typically when refering to a part of the firmware that is living in its own git repo. Mostly the names of such projects start with Kaleidoscope- .
The term plugin is commonly used for a piece of software that serves as a module for an existing software and inter-operates with it via a well defined API. Mostly this also requires the module to be run-time loadable (plug and unplug). The latter is not the case for the firmware as it is a monolith. So what we commonly call firmware plugins are, in my opinion, not plugins in a strict sense.
There are some projects - I use the term projects here for everything that lives in its own git repo - that do not provide firmware parts, or do not use the plugin-API or only provide headers (Kaleidoscope-Ranges) or do provide code that only interacts with the firmware (e.g. Kaleidoscope-Hardware-Virtual), but are not actually part of the (device-) firmware.
We should consider using more distinctive terms for those different types of projects, e.g.
- plugin for everything that is linked into the firmware and uses the plugin-API.
- module for everything that is linked into the firmware (including plugins).
- project (or maybe a better suited term) for everything that is related to the firmware (including modules), but not necessarily compiled code.
What do you think?