Should stmps use a Go subsonic 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.