Implement Subsonic API for audioserve

[izderadicka]

This can help with limited clients - especially mobile clients - as there are already couple of Subsonic API clients.
Not sure if we can match Subsonic API to audioserve, but at least it worth to research.

[wtanksleyjr]

There is an informal extension to the Subsonic API, "Booksonic". It would be interesting indeed to go in that direction. :) By "informal" I mean that it's defined by a client and server coded by the same person, and by "extension" I mean that it's defined in a way that allows arbitrary Subsonic clients to be able to use the Booksonic server.

…

-Wm

On Wed, Sep 8, 2021 at 11:52 AM Ivan Zderadicka ***@***.***> wrote: This can help with limited clients - especially mobile clients - as there are already couple of Subsonic API clients. Not sure if we can match Subsonic API to audioserve, but at least it worth to research. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#59>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJ7H6JRSEFWUF6ARI6Y5TDUA6WFHANCNFSM5DVPARXQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[ghost]

I believe there was a issue over at Gonic (A Similar application that is more specialized for music) sentriz/gonic#89. This application might run into similar issues, since the folder structure is more loosely defined?

On that thought, I think this is also why Mstream (https://github.com/IrosTheBeggar/mStream/) decided to not support subsonic and roll their own flutter application. I can't seem to find the issue, however.

[izderadicka]

I have been looking into Subsonic API, key thing is that it's very much database oriented, each object - and Directory and Child are main objects that would be interesting for us - has unique key, which is string (as per XSD definition, but in practice (airsonic) server uses integer key. Easiest way for us would be using collection_id+path as key, but it'll mean that key can be quite long (up to 4096 characters). Though XSD does not have any limitation on id string size I doubt that clients will support support it.
The disparity between our model based on paths only and relational model Subsonic API is first think to solve, and I think practically it'll mean to somehow assign persistent ids to folder and audio file, which was something I wanted to prevent.
Will give it some thoughts, but it's not priority now.

[izderadicka]

After a while I reconsidered it and I think it'll not worth to invest effort into subsonic API.
Main points are:

• Subsonic "logic" is much different from audioserve, implementation will be complicated and will force some constructs which we will not need otherwise
• Subsonic API is not well designed generic API, it's much focused on particular application, use case. Audioserve API is not much better, but two are not much compatible, so why to care to introduce another legacy.
• I think Subsonic is declining anyhow.
• Main reason for Subsonic was broader platforms support, but with new PWA client it is achieved with some limitations, where most is around opus transcoding, which Subsonic API will not solve.

I'll keep issue opened, for other arguments to come, but do not expect much progress.