Replies: 4 comments 1 reply
-
At some point @sentriz mentioned that we should follow the way Go serializes arrays in XML, which is exactly what this is. And Supersonic is actually using XML right now, since I started from forking an unmaintained API client library that used XML. I am not opposed to switching that library to JSON - just pointing out that this is what Gonic and LMS are already doing for XML and it works fine. |
Beta Was this translation helpful? Give feedback.
-
that looks right to me, and it also looks like our existing support for array-like things in the subsonic XML protocol. for example the search3 response has a list of artist, song, track, etc - and it looks the same as that. this is what i have for gonic https://go.dev/play/p/A-4iicX2fP1 i would not be in favour of ditching XML personally because it becomes a pain to keep internal types that marshal to JSON all of the time but marshal to XML only some of the time (assuming we would support fancier types) and I still use XML only clients like DSub and jamstash occasionally |
Beta Was this translation helpful? Give feedback.
-
Ah, thanks for the clarification folks. And yeah @sentriz, I'm also not in favour of ditching XML, as DSub is may main music player at the moment, and I want to keep supporting it. |
Beta Was this translation helpful? Give feedback.
-
There's no ditching of XML since the goal of OS is compatibility :) |
Beta Was this translation helpful? Give feedback.
-
Hey folks, I've been away for a while, and there's quite a lot to catch up here. Not sure if you discussed this before, but should we support XML in OpenSubsonic, or just JSON? I'm asking because I don't see how XML payloads should be represented for example for the
genres
attribute. This is what I'm currently getting:I'm pretty sure this is not what we want. I'm not sure if we can have duplicated attributes, like:
So, what should we do? Was this discussed at all? Couldn't find anything in a quick search.
Beta Was this translation helpful? Give feedback.
All reactions