02-12-2021, 12:05 AM
Hi all,
So I'm relatively new to moOde and have just scratched the surface of the stuff I want to use it for. It's great!
I think that it can be improved by presenting a unified API (or protocol). As far as I know, everything is configured and controlled by the web UI. It presents the system as a unified whole, but that is only superficial. If you want to control or query the system from outside the web UI, then you talk directly to the different subsystems, for better or worse. This works just fine for mpd, because it is made to be a back end and the communication is intrinsic to it working. This doesn't work for a lot of other scenarios (switch to bluetooth streaming, is airplay on, etc).
Many people are trying to make moOde theirs through different customizations which is to be expected, given the hardware and open source environment. I'm proposing that we define an interface to query and control all aspects of moOde. This will make a very flexible system that will be far easier to integrate with and manage for end users. For example, it would be very easy to add a remote control to the system (using lirc) with a unified programmable interface which would include switching to/from bluetooth.
I picture an API and network protocol that would mirror a lot of the stuff that moOde uses from mpd (in fact, just pass through mpd specific stuff) but also include everything else moOde does. Switch inputs, and report what input is being used, pass along song metadata when available from the different sources, enable/disable DSP, and so on.
This isn't a little bit of work, but there are big positive results. Firstly, it presents moOde as a single appliance and not a group of different apps and systems bundled together. Secondly, one interface to configure, control, and query the system simplifies programming for and controlling the system internally and externally. And finally, it makes the whole system very nimble and configurable.
Speaking to my last point there, having this API/protocol would provide a huge amount of flexibility to the back end. I know this system is built around PHP and a server-side design, but this necessarily requires all of that infrastructure and overhead. There is a great legacy there and much effort sunk into it to make it the best it can be. Unfortunately, my Pi 2B often skips playback if there is too much going on with the web UI and if I have a big playlist it can be quite unresponsive. With a system-wide api, a daemon could be the brain of moOde and be talked to via TCP (just like mpd and almost every other internet service). This would allow for different interfaces to be developed alongside the current web UI (and simple changes to the current UI to talk to the daemon).
If moOde doesn't need a whole web stack to run, then it would work in more resource constrained situations as well as allowing for more room to grow. In the long term, a daemon would replace the PHP interface for query and control. This would be a long-term goal and a direct result from providing a unified interface for the whole system. The current web UI would stay on as the reference interface while a more modern, client/server interface could be created.
Not a simple proposal to execute and so would take some planning and coordination, but I think that moOde would be better off for it and be more future proof. Thoughts?
So I'm relatively new to moOde and have just scratched the surface of the stuff I want to use it for. It's great!
I think that it can be improved by presenting a unified API (or protocol). As far as I know, everything is configured and controlled by the web UI. It presents the system as a unified whole, but that is only superficial. If you want to control or query the system from outside the web UI, then you talk directly to the different subsystems, for better or worse. This works just fine for mpd, because it is made to be a back end and the communication is intrinsic to it working. This doesn't work for a lot of other scenarios (switch to bluetooth streaming, is airplay on, etc).
Many people are trying to make moOde theirs through different customizations which is to be expected, given the hardware and open source environment. I'm proposing that we define an interface to query and control all aspects of moOde. This will make a very flexible system that will be far easier to integrate with and manage for end users. For example, it would be very easy to add a remote control to the system (using lirc) with a unified programmable interface which would include switching to/from bluetooth.
I picture an API and network protocol that would mirror a lot of the stuff that moOde uses from mpd (in fact, just pass through mpd specific stuff) but also include everything else moOde does. Switch inputs, and report what input is being used, pass along song metadata when available from the different sources, enable/disable DSP, and so on.
This isn't a little bit of work, but there are big positive results. Firstly, it presents moOde as a single appliance and not a group of different apps and systems bundled together. Secondly, one interface to configure, control, and query the system simplifies programming for and controlling the system internally and externally. And finally, it makes the whole system very nimble and configurable.
Speaking to my last point there, having this API/protocol would provide a huge amount of flexibility to the back end. I know this system is built around PHP and a server-side design, but this necessarily requires all of that infrastructure and overhead. There is a great legacy there and much effort sunk into it to make it the best it can be. Unfortunately, my Pi 2B often skips playback if there is too much going on with the web UI and if I have a big playlist it can be quite unresponsive. With a system-wide api, a daemon could be the brain of moOde and be talked to via TCP (just like mpd and almost every other internet service). This would allow for different interfaces to be developed alongside the current web UI (and simple changes to the current UI to talk to the daemon).
If moOde doesn't need a whole web stack to run, then it would work in more resource constrained situations as well as allowing for more room to grow. In the long term, a daemon would replace the PHP interface for query and control. This would be a long-term goal and a direct result from providing a unified interface for the whole system. The current web UI would stay on as the reference interface while a more modern, client/server interface could be created.
Not a simple proposal to execute and so would take some planning and coordination, but I think that moOde would be better off for it and be more future proof. Thoughts?
