Hey All,
As a follow up to our discussion about making Volumio2 modular, I’d like to propose we move to a different directory structure. The structure shown here is one example, modeled after the hierarchy in how our code runs. This structure helps with modular loading. It does not not have to look exactly like this, though, to get the same benefit.
To start Volumio2, you run “index.js”. This starts “app/index.js”, “httpserver/index.js”, and “worker.js”. The “app/index.js” is currently known as “core-commandrouter.js”. This loads the databases “db_musiclibrary”, “db_devices”, and “db_volume”. Then it looks in the controllers directory and starts each controller it finds, and looks in the interfaces directory and starts every interface it finds.
As longs as we keep a consistent convention for the methods every controller and interface is expected to offer, and which methods they may execute in the core, you can drop any controller and interface you want into these folders.
About plugins :
Where will they be placed ?
What kind of interaction with the system will be allowed ? for instance
Adding function/ page in the webUI ? (language)
Adding output work ( DRC, equalizer etc…)
Adding hardware (a new dac) / protocol
Adding the possibility to work with other music streamer ( google music, Qobuz, deezer, Jamendo)
Adding other service ?
…
Hmm I guess the controller and interface plugins have a dedicated place to live, but I haven’t thought about other plugins yet…
The interface plugins will allow us to add completely new user interface protocols. You can also make just a new user interface communicating with the included websocket interface plugin. Adding a new controller plugin will allow you to connect to new music services, like some of the ones you mention.
As far as a location for system and hardware control plugins, what are your recommendations?
Well,It’s a hard question for me, as I’m not able to code, I can hardly tell you what will be the good way…
The most difficult to evaluate, is interaction of a plugin with the system via the websocket. I’m especially thinking of egalizer or DSP / DRC. This controller should affect the output of all services.
I’m thinking to an other request I saw several time in the forum : the ability of pre-configuring Volumio, especially the network and the wi-fi. A possible scenario :
1 - download the Volumio image
2 - write the sd card
3 - mount the sd card
4 - modifing a text file containing basic and easily readable config parameters such wifi essid / passawd
5 - booting the device (RPI or other) with the sd card. - If file exist then apply it at boot
What do you think of that ?
Yes, we are using plain-text configuration storage files (json). This way the system can be configured just by editing them (and we can build a volumio-config tool on the website…), plus the configuration will survive on system updates…
That is definetely a more rational way to organize the content ,and this will allow to add a sort of “intelligence” to the player: knowing where to look it can understand which services are available.
I would just edit a couple of things from steven, (of course my 2 cents):
If you check the code right now you see two main sections for modules: controllers and plugins.
Even though the two share common interfaces they focus on different areas. Controllers are core modules and won’t be under user controle in terms of installation, uninstallation, enabling etc. PLugins instead are supposed to be updated and added/removed by the user.
That’s one of the main reason for different storage are in the code. Moreover plugins are grouped in categories (a subfolder in plugins) for better organizing the plugins.
I think there’s a bit of misunderstanding. The app/controllers folder is intended to only be for music service controller plugins, and the app/interfaces folder is intended to be only for user interface plugins. The command router expects everything in the Interfaces folder to respond to a standard set of UI push commands, and everything in the Controllers folder to respond to a standard set of music control commands. Please refer to the main wiki page for an explanation on this system.
I see you have added non-music service control related items to the app/controllers folder. Instead, I recommend we place any core components in the app/ folder directly, and any plugin that is not a music controller or user interface in the app/plugins folder.
Yes, that makes sense. I assumed that we could divide the things that are shipped with volumio and things that can be added\removed, that’s why we placed the new stuff in the controller folder. But yeah, in a week or so we should define how to properly classify and place such components. I would suggest a slight modification of the logic that steve set up:
since mpd itself will be “interchangeable” in the future, we should probably move it in the music services plugin folder, and maybe rearrange core componets in a way that’s more clear of what pertains to volumio core…
The logic here should allow us to add\remove also core components fast (just adding the folder with its index.js, config.json and localization files, and at the same time keep a bit of logic placement…
Any suggestion about that?
Michelangelo, we can imagine to allow lifecycle management to controllers also. They are indeed very similar to plugins. This means that any change will reflect to references in other plugins to be updated.
I suggest to have another telco as soon as you’re back to align anyone on the internal structure.
Moreover I see that we have to discuss little bit how the core is currently managing plugins. Indeed we worked together on that but we missed on syncing with Steven. Maybe some corrections on code are needed.
Agree on a new telco to align everybody and set a standart. Unfortunately I think we should wait for next sunday, as it’s the only time we can get in sync with California time (and steve is not at work).
So is ok for everybody to have a skype call on 16th august at 21:00 italian time?
Sure, a teleconference sounds great. I’m willing to support whatever directory structure works best for the plugins system that Massi is working on. Right now still trying to balance Volumio development time with work!
