[API Request] Generic 'Key-Value' store

[acroyear]

Type of change

API extension

Proposal description

With SubFire Radio, I have to have a place to store the information about a user's "radio stations" (a kind of programmed playlist, where it can shuffle songs based on their musicDirectory, artist, album, similar artists, top songs, etc, most of the various api params that can return songs directly or through nested calls).

I also have a feature of a 'remote control' where i can write what the remote instruction should be and the client reads that, processes the instruction, and resets the field.

Currently, I am using the comment field of playlists for both, because I have no standard mechanism to do this. For the remote, i can't use the chat feature, both because it gets noisy seeing those instructions pass through on the sidebar of the main app, and because several 3rd party implementations don't support the chat feature (Navidrome and Ampache in particular).

So I would rather have a kind of generic key-value, a place where i could put "subfire.radio.station..name" as the key, and the json values of the station details in the value.

Obv I would need the ability to search for matching keys ("subfire.radio.station.." for the list of stations that user can edit, or "subfire.radio.station." for all stations to show for listening). If that wasn't provided, well, I could just put the list of stations in its own key-value entry.

So it gives some degree of app-specific customization without granting full access to the DB by exposing an SQL endpoint...which wouldn't be generic enough given that other implementations might not be SQL based.

Backward compatibility impact

totally new endpoint, so no impacts

Backward compatibility

• No backward compatibility impact.

API details

GET /rest/data?search=<pattern>
Accepts a wildcarded pattern and returns all keys and values that match. Returns success + empty array if no matches.

GET /rest/data/key
Returns the key-value that matches that key, or error code 70 if not found.

GET /rest/data?key=<key>&value=<value>
Sets the key-value and returns empty success

GET /rest/data?key=<key>
Without the value parameter, deletes the key-value and returns empty success

Sticking to the GET pattern here as that's the subsonic norm, even though that isn't very rest-like.

Security impacts

Other apps would be able to access the same data and potentially corrupt it.

I can't rely on the client string for unique SubFire apps because there are multiple clients in the SubFire suite (about 8 so far), and the library core allows for other apps to use their own.

Potential issues

No response

Alternative solutions

As noted, for now i'm hacking through playlist comments, but it requires creating playlists to hold that info for the remote control and that really floods the playlist page when it is seen by non-SubFire clients.

[Tolriq]

GET /rest/data?key=<key>
Without the value parameter, deletes the key-value and returns empty success

Not a fan of this as it's error prone. To keep get I'd add a parameter or specific endpoint.

[lachlan-00]

yeah i wouldn't delete anything without explicit request

[lachlan-00]

Ampache uses a user-data table for things like this. so i think that's not a bad thing to have.

I'd call it userData rather than data as it's client and not server data

I would also take the search away and just return the list with no params
userData with no parameters: return the list of userData in key value pairs

Ususally i wouldn't delete this data in the Ampache user data table but if you delete anything i would add a parameter to delete

[Tolriq]

Since Subsonic API does not really handle the concept of multiple users sharing the same library, and different client may use this to store different data but with the same name.
I wonder if adding a third parameter to group those key values could help solve a few cases.

[lachlan-00]

the ampache table has 3 columns so a 4th column of client would help there. still might not need to be client-based if the server takes it over?

[lachlan-00]

client is required so the server can take that load

[acroyear]

I can say in this case that I do need to have things cross-user as I do share my server with my family. A "station", like a playlist, might be private or public, and usually is public.

As for "just give me everything" - I've never been a fan of that. Any key-value store system could start getting large and making all clients get all key-values instead of just the values for keys they know about seems wasteful.