Do after #65.
Second part of our join handshake. When a host receives a JOIN message, after the interpreter adds the client and does everything else it needs to for #65, it should additionally initiate sending a JOIN_RESPONSE back to that client.
The message should have a payload that includes the following, plus any other info that the client will need TBD
A boolean that can be used to determine whether the join request is accepted/rejected. For now it should always be true for accepted. If it's false the other fields don't matter.
The room code of the room, as a string, so that the client can get the current room code
The usernames of the users in the room, represented in some serializable form. The client should know who the host is, and the client's SessionModel should also know that the local user is not the host user. (This might involve an update to the diagram loader)
Leave a placeholder for the diagram itself, which does need to be sent.
When receiving this kind of message (on the client end only - a host should ignore these) the message interpreter should populate this information. At this point the message interpreter will definitely need access to the SessionModel if it did not already for #65.
Andrei486
commented
7 months ago
Do after #65. Second part of our join handshake. When a host receives a JOIN message, after the interpreter adds the client and does everything else it needs to for #65, it should additionally initiate sending a JOIN_RESPONSE back to that client. The message should have a payload that includes the following, plus any other info that the client will need TBD
When receiving this kind of message (on the client end only - a host should ignore these) the message interpreter should populate this information. At this point the message interpreter will definitely need access to the SessionModel if it did not already for #65.