germanferrero
commented
3 years ago From my point of view we should definitely work on keeping and improving the LimeApp's modularity, in the sense of the code being grouped in highly cohesive loosely coupled functionalities, such as: remote-support, pirania, alignment, firmware-upgrade, etc. Each of these modules having the possibility to add more than one screen in the application, a banner on startup, or other elements rendered in screens defined by cross components.
This will set a good basis for a later implementation of plug-ability, where you can define at compilation time which functionality to include in your final build of the LimeApp. But it is not something that we are needing right know, is it?
That being said, having the wording "plugins" in a non pluggable app is misleading as you said. And it would be awesome to rename plugins to just "modules"
nicopace
While reading the code there is a directory that mentions plugins, and they are included automatically at compile time, so it easens adding new plugins. The plugin wording might suggest that this functionality can be added or removed, but as it is closely tied to the code deployed serverside, and the way it is distributed right now is in a package with a predefined set of plugins, it actually looks more as components than to plugins.
On the other hand there might be the need for a flexible plugin architecture, so there needs to be a reflection in relation to whether we need this architecture right now or is it better to simplify it for now, and also if it makes sense and it is possible to have a plugin architecture or not.