playlist concurrency

[Whuppee]

overlaps with #110 but also very much its own issue—

the discord client needs something like Player's embeds to sync playlist edits (I've added the label)

the web client should probably register something similar with the server when a playlist is displayed, so edits can be selectively synced instead of every modification needing to be sent to every client, even ones without the playlist loaded
(not that there should be that many clients, but still. every change, in real time, when they're not looking at the playlist?)

could fetch playlists on mount and push changes occasionally? but except for anyone watching/ helping, throttle updates instead of pushing a hundreds when someone's creating/ rearranging a playlist drag by drag

right, yep. have to register and selectively sync server side, else every client is potentially watching/ helping, else desyncs

[Whuppee]

pushing playlists occasionally in the background seems like something we should know how to do—dealing with the slight desync potential, I mean. unsure how to handle that elegantly. should be slightly more responsive to the user though

makes sense to always call /playlist when first displaying a playlist though. do nothing if it comes back identical, reject/ reconcile user changes in the less likely scenarios where it comes back different

.
thinking about registration; it could (should?) be done in that same web endpoint—it's already doing all the same checks the web sockets do, should produce the same user id already mapped to a socket (and unimportant, but if that mapping goes alongside the current websocket handling, it's already local to the web endpoint)

the client could fetch /playlist and use its web socket to register, where all the same checks are done. I think I'd already want fetch to check if that id matches a web socket though. then its response could error; cause the client to try reestablishing the socket, tell the user there's a problem, lock modification? and by that point it should just register

though I think I would want the client to use its socket to tell the server it's closed a playlist and to de-register it

currently thinking our sockets should take on the form we're using most everywhere; a switch around type:
syncing a 'player', 'playlist', other future things? clients use socket messages to de/register different types of "listener",
and outgoing syncs use the type to grab the set of ids to filter clients against