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.
app/
controllers/
mpd/
db_tracklist/
index.js (currently controllers/controller-mpd.js)
gmusic/
db_tracklist/
index.js
spop.js/
db_tracklist/
index.js (currently controllers/controller-spop.js)
db_musiclibrary/
db_devices/
db_volume/
interfaces/
mpdemulation/
index.js (currently controllers/interface-mpd.js)
helper.js (currently controllers/interface-mpd-helper.js)
websocket/
index.js (currently controllers/interface-webui.js)
deviceselector.js
index.js (currently controllers/core-commandrouter.js)
musiclibrary.js (currently controllers/core-musiclibrary.js)
playqueue.js (currently controllers/core-playqueue.js)
statemachine.js (currently controllers/core-statemachine.js)
volume.js
httpserver/
www/
scripts/
stylesheets/
error.ejs
index.ejs
index.js (curently server.js)
routes.js (currently routes/index.js)
node_modules/
...
.elsintrc
.gitignore
index.js (currently bin/www)
package.json
readme.md
worker.js (currently bin/worker)
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.
