[Feature] Replace bespoke Subsonic API with external library

[xxxserxxx]

Rather than maintaining an internal, bespoke Subsonic API library, should we use something like go-subsonic? The downside would be an external dependency; the upside is that that library, in particular, is more complete than the home-brewed interface. Plus it's less work for us to maintain.

[spezifisch]

That's a good idea and I now think the answer is definitely yes.
There is a maintained fork by the Supersonic author @dweymouth at https://github.com/supersonic-app/go-subsonic which could be used (we already use a common go-mpv).

This might be a post-1.0.0 thing though IMO.

[xxxserxxx]

Ok. I'll look at the libraries and see if I end up with an opinion. I agree, it's not critical; I haven't needed it, although the search feature started pushing the boundaries as I added functions for calling more of the Subsonic endpoints and had to add some types.

I guess I should stop the fun stuff (adding features) and start knocking things out of the 1.0.0 milestone.

[dweymouth]

If you're considering using my go-subsonic fork we can discuss any API changes that would be nice before tagging a stable 1.0.0. I was thinking about making all the endpoints context-aware, to allow for controlling timeouts on a per-request basis, etc.

[xxxserxxx]

If you're considering using my go-subsonic fork we can discuss any API changes that would be nice before tagging a stable 1.0.0.

@dweymouth , where would you like to have this discussion? I haven't discussed a timeline with @spezifisch on the stmps 1.0.0 release, although I'm thinking we're getting reasonably close. It's likely that immediately thereafter, we'll be looking at replacing a fair chunk of bespoke code with libraries: your's for (Open)Subsonic, and another for some of the GUI widgets that were crafted in stmps.

You're right that it's the right time to be discussing API fixating, and in particular the data model. ABI changes aren't as disrupting as model changes.