-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Control MPD via REST API #1808
Comments
This has been requested a few times over the last 2 decades, but I'm not interested in spending time on this. |
Is it really a good idea to having to maintain two APIs? Also, most languages probably have a client library for MPD by now, so I don't see much benefit in providing a second API. And removing the existing API is also not an option, since that would break every single existing client out there for no good reason. A REST API might be nice for sure, but I don't see the benefits weighing out the extra burden it puts on the maintainer(s) of this project. |
No, there shouldn't be more than one API - and that "togglempc" project is an example how it should not be done - it specifies a completely new protocol transported over HTTP. What would be possible is tunnel regular MPD commands through HTTP requests (or WebSocket). That way, web interfaces could use this interface instead of having to implement their own HTTP/MPD bridge, and all new protocol features would be available immediately. But anyway, I'm not interested in implementing this - I'm not intersted in any web interfaces or HTTP APIs - I'm just trying to outline what could maybe be acceptable and what would certainly not be. |
Although both of you said no, @MaxKellermann's comment is more soothing :) |
Ha ha, no, actually I do HTTP all day at dayjob - I wrote a whole web server that runs millions of websites :-) I'm not convinced that adding a HTTP API to MPD will be very useful. That's just my personal taste. The day has only so many hours - if I'd spend time on such a HTTP API, I would have less time for things I consider more important, it's that easy. There are so many things I'd like to hack into MPD, but there's so little time, so I have to choose wisely. If there are so many people who believe a HTTP API is important, they should implement it. Don't expect somebody else to do it, just do it yourself. |
Do you maintain a roadmap vision (or to-do list) somewhere, so people can review and comment? (I'm actually against voting for features, but that's another conversation) |
I have no (written) roadmap, only numerous ideas in my head. I don't think discussing those ideas is helpful as long as I don't have the time to implement them. And even if I do have time to implement them, comments/reviews don't help a lot. Everybody who has enough interest in MPD should write code instead of reviews. That's the only thing that really counts. |
I also believe a good approach would be to expose regular MPD protocol over a websocket (cf. #1511). |
Feature request
I think it would be worthwhile to expose a rest api so clients and users can control and retrieve information from MPD. Yes, there's the awesome mpc client and the others, but the rest api kind of standardizes the interface and makes MPD agnostic to the clients.
For an instance, now, in order to be client agnostic I'm interfacing with MPD via netcat or telnet, but rest could be more robust with the responses such as long playlists via json and what not. I found a GitHub project that started to address this, but it has been deserted and really that would be much preferable if it could be out of the box or at least an MPD plugin I can turn on and off according to my use with MPD
https://github.com/christianwicke/togglempc
The text was updated successfully, but these errors were encountered: