Syncplay Protocol v1.6.7

[RozeFound]

I'm trying to implement your protocol in my application, and I was confused with this thing: Server << {"Set": {"user": {"Bob": {"room": {"name": "SyncRoom"}, "file": {"duration": 0, "name": "filename", "size": 0}}}}} What the heck is this: {"user": {"Bob": How can I access data in the row if the key can be ANYTHING?

[Et0h]

Every Syncplay user has a username. In this example, one of the users has the name "Bob" and so this message specifies information regarding what Bob is watching.

If you want to see how this is implemented in practice, you can see the Syncplay source code at https://github.com/Syncplay/syncplay and specifically the protocol code at https://github.com/Syncplay/syncplay/blob/master/syncplay/protocols.py

What are you trying to implement the protocol for?

[RozeFound]

I mean, why the json key doesn't have a constant name?

[Et0h]

The user won't always be called "Bob". Sometimes they might be called "Alice".

See https://syncplay.pl/about/protocol/ for details on different uses of the "Set" messages. It is based on Syncplay 1.2.7, so hasn't been updated to show the protocol for chat, playlist and readiness messages but all that can be seen within the Syncplay protocols.py file.

[RozeFound]

I understand, but JSON keys must be constant for easy accessing data inside. Like "User":{"username":"Bob", ...}

[RozeFound]

JSON keys with mutable names just hard to deserialize.

What are you trying to implement the protocol for? @Et0h

Of course for what it was created, for video playback synchronization.

[Et0h]

I agree that the protocol is not ideal in terms of ease of re-implementation, but it's what we've got and changing it would harm forwards and backwards Syncplay combability. If you are trying to make something which is compatible with Syncplay then look at how Syncplay parses it to figure it out. If you do not need compatibility then feel free to revisit many of the protocol design decisions that we made.

[RozeFound]

Why just not make something like this?

if ver > 1.6.8: 
    return {"User": {"username": "Bob", ...}}
else: return {"User": {"Bob": {...}}}

Or you just don't want to make it easier to use?

[Et0h]

How would changing the protocol make anything easier for anyone? We want to maintain forward and backwards compatibility, so it just means every implementation would need to support both versions of the protocol, thus doubling the complexity.

[RozeFound]

Okay I understand your point, thanks for the answer.