Control MPD via REST API

[roizcorp]

Control MPD via REST API

[MaxKellermann]

Or did HTTP do something to you in the past? :)

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.

[roizcorp]

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)
Perhaps that would help you add features that are more mature, or just get the reception of your ideas before actually doing them

[MaxKellermann]

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.

[MaxKellermann]

This has been requested a few times over the last 2 decades, but I'm not interested in spending time on this.

[NexAdn]

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.

[MaxKellermann]

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.

[roizcorp]

Although both of you said no, @MaxKellermann's comment is more soothing :)
I'm not a developer, I'm a product manager...I think of a potential for any software to be able to grow on its own and to develop (or maintain) an ecosystem.
Clearly, I respect your decision, and I'm very grateful for what you do for MPD, but may I ask why you're not interested? Is it because it is not an actual "feature" that is music playing related? Or did HTTP do something to you in the past? :)