[GH-ISSUE #204] implement ampache XML api #147

Open
opened 2026-02-26 02:32:16 +03:00 by kerem · 5 comments
Owner

Originally created by @mikk150 on GitHub (Jan 28, 2016).
Original GitHub issue: https://github.com/koel/koel/issues/204

Could we implement Ampache XML api, so users could use Ampache compatible players
I know Ampache API seems quite bad, but hey, free players for everyone!

https://github.com/ampache/ampache/wiki/Clients

Api documentation
https://github.com/ampache/ampache/wiki/XML-API

Originally created by @mikk150 on GitHub (Jan 28, 2016). Original GitHub issue: https://github.com/koel/koel/issues/204 Could we implement Ampache XML api, so users could use Ampache compatible players I know Ampache API seems quite bad, but hey, free players for everyone! https://github.com/ampache/ampache/wiki/Clients Api documentation https://github.com/ampache/ampache/wiki/XML-API
Author
Owner

@phanan commented on GitHub (Jan 29, 2016):

I'm not against the idea, but not a fan either. Quite frankly I'm not fond of the fact that Ampache uses XML for their API (maybe due to historical reasons). That its API became the de-factor standard thanks to its popularity, and now every other media service should implement the obsolete API in order to gain some player support, is even sadder. This isn't of course, by any means, to bash Ampache or its developers.

<!-- gh-comment-id:176513009 --> @phanan commented on GitHub (Jan 29, 2016): I'm not against the idea, but not a fan either. Quite frankly I'm not fond of the fact that Ampache uses XML for their API (maybe due to historical reasons). That its API became the _de-factor_ standard thanks to its popularity, and now every other media service _should_ implement the obsolete API in order to gain some player support, is even sadder. This isn't of course, by any means, to bash Ampache or its developers.
Author
Owner

@mikk150 commented on GitHub (Jan 29, 2016):

Yes, I agree. I am kind of forced to use Ampache right now because of player support(and I am not eager to write python to support my fav media player that also supports ampache quite well), despite the fact that Ampache is too complicated and ugly :). There is nothing wrong with XML Api (take a look at SOAP), but Ampache-s way is messed up. Can't fix it though. If only there was pretty standard that works...

<!-- gh-comment-id:176671310 --> @mikk150 commented on GitHub (Jan 29, 2016): Yes, I agree. I am kind of forced to use Ampache right now because of player support(and I am not eager to write python to support my fav media player that also supports ampache quite well), despite the fact that Ampache is too complicated and ugly :). There is nothing wrong with XML Api (take a look at SOAP), but Ampache-s way is messed up. Can't fix it though. If only there was pretty standard that works...
Author
Owner

@Afterster commented on GitHub (Jan 29, 2016):

Ampache XML api is indeed for historical reason. I'm not a big fan of it neither even if I'm the current Ampache maintainer (this was created on the early age of the project). But it is, and will be, keep for backward compatibility.
About being complicated/ugly, that's partially a matter of taste, a lot of effort was done with Ampache 3.7 and 3.8 on feature simplification and better UI. Ampache API itself is still updated on latest version and except that it is based on xml, there is no real issue with the API. More a matter of taste here again.
For other stuffs, I will say https://github.com/phanan/koel/issues/104#issuecomment-165973301 => I don't care about the project, having a consolidated open-source media community is more important here for me, and the API has a driving role.

<!-- gh-comment-id:176734103 --> @Afterster commented on GitHub (Jan 29, 2016): Ampache XML api is indeed for historical reason. I'm not a big fan of it neither even if I'm the current Ampache maintainer (this was created on the early age of the project). But it is, and will be, keep for backward compatibility. About being complicated/ugly, that's partially a matter of taste, a lot of effort was done with Ampache 3.7 and 3.8 on feature simplification and better UI. Ampache API itself is still updated on latest version and except that it is based on xml, there is no real issue with the API. More a matter of taste here again. For other stuffs, I will say https://github.com/phanan/koel/issues/104#issuecomment-165973301 => I don't care about the project, having a consolidated open-source media community is more important here for me, and the API has a driving role.
Author
Owner

@phanan commented on GitHub (Jan 29, 2016):

I don't care about the project, having a consolidated open-source media community is more important here for me, and the API has a driving role.

I'd agree, hence "not against the idea." Will need to buy some time for this though. Unless, of course, someone can send a PR over.

<!-- gh-comment-id:176738827 --> @phanan commented on GitHub (Jan 29, 2016): > I don't care about the project, having a consolidated open-source media community is more important here for me, and the API has a driving role. I'd agree, hence "not against the idea." Will need to buy some time for this though. Unless, of course, someone can send a PR over.
Author
Owner

@0xcaff commented on GitHub (May 14, 2016):

Why not just create a new API standard and players? The beetbox project has a solid proposal.

<!-- gh-comment-id:219228317 --> @0xcaff commented on GitHub (May 14, 2016): Why not just create a new API standard and players? [The beetbox project has a solid proposal](https://github.com/beetbox/aura).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/koel-koel#147
No description provided.