Renaming the field, on the golang side, to match the JSON.
And then fix its actual value, when it is send.
So the way it works, for future reference:
Client send lock request -> World broadcast of {id: "42", result:1, lock_owner: "AAA"}
Somebody else sends lock request -> Response only to this user {id: "42", result:0, lock_owner: "AAA"}
Somebody else sends unlock request -> Response only to this user {id: "42", result:0, lock_owner: "AAA"}
Client send unlock -> World broadcast of {id: "42", result:1, lock_owner: "UUID(nil)"}
--> so 'result': 0 goes to 1 user. 'result: 1' is world broadcast.
If client wants to know (currently we don't visually show it, but for the future): have to use the lock_owner field to figure out if a lock or unlock was send, by comparing against uuid nil value.
Or can use the non-nil UUID to show a message who's holding the lock.
Renaming the field, on the golang side, to match the JSON. And then fix its actual value, when it is send.
So the way it works, for future reference: Client send lock request -> World broadcast of
{id: "42", result:1, lock_owner: "AAA"}Somebody else sends lock request -> Response only to this user{id: "42", result:0, lock_owner: "AAA"}Somebody else sends unlock request -> Response only to this user{id: "42", result:0, lock_owner: "AAA"}Client send unlock -> World broadcast of{id: "42", result:1, lock_owner: "UUID(nil)"}--> so 'result': 0 goes to 1 user. 'result: 1' is world broadcast. If client wants to know (currently we don't visually show it, but for the future): have to use the lock_owner field to figure out if a lock or unlock was send, by comparing against uuid nil value. Or can use the non-nil UUID to show a message who's holding the lock.