You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Requesting a few new WebSocket message types (maybe as a form of "subtype" of one another, but a dedicated type should be fine as well for most of them):
lobby_invitation self-explanatory, user gets invited to a lobby (already exists as HTTP API, but there's no way to signal it to a client yet)
lobby_kick user gets kicked out of his current lobby (of course, only when kicking of users gets implemented)
lobby_closed user's current lobby gets closed (may be combined with the previous, but please differentiate those two cases by some flag); the result is the same: the lobby is (temporarily?) inaccessible
game_finished if a game has been finished for some reason, e.g. victory or resigning (which means: the player may attempt to download the latest game state, but should remove the game from the active list)
friend_request for new incoming friend requests (same form as FriendRequestResponse?)
friendship_change if the other user rejected established friendship or dropped a friend request (to update the client's local view)
account_updated if the user's local account has been changed (e.g. new username)
account_deleted same as above, may be combined; the WebSocket may be closed after this message, but it's useful to tell a client that his account got removed, because otherwise it would try to-relogin due to invalid session and ultimately break with "unknown username", which is not very user-friendly and there's no better way to determine this situation otherwise
Use snake_case or CamelCase or whatever you want.
Of course, all of those are up to discussion and refinement.
The text was updated successfully, but these errors were encountered:
lobby_invitation is already implemented. If an inventation is created, a WsMessage::IncomingInvite is sent
lobby_kick: Sounds fine
lobby_closed: If a client was kicked, I'll only invoke lobby_kick. If he tries to rejoin the lobby, he will receive either receive a MissingPrivileges or a new error type (I've not decided that yet). If the lobby was closed this message will be invoked.
game_finished: How does the server know this?
friend_request: Sounds fine
friendship_change: Sounds fine
account_updated: Sounds fine
I don't see the point in account_deleted. If a user has deleted its account, he shouldn't be very surprised by a unknown username.
Requesting a few new WebSocket message types (maybe as a form of "subtype" of one another, but a dedicated type should be fine as well for most of them):
lobby_invitation
self-explanatory, user gets invited to a lobby (already exists as HTTP API, but there's no way to signal it to a client yet)lobby_kick
user gets kicked out of his current lobby (of course, only when kicking of users gets implemented)lobby_closed
user's current lobby gets closed (may be combined with the previous, but please differentiate those two cases by some flag); the result is the same: the lobby is (temporarily?) inaccessiblegame_finished
if a game has been finished for some reason, e.g. victory or resigning (which means: the player may attempt to download the latest game state, but should remove the game from the active list)friend_request
for new incoming friend requests (same form asFriendRequestResponse
?)friendship_change
if the other user rejected established friendship or dropped a friend request (to update the client's local view)account_updated
if the user's local account has been changed (e.g. new username)account_deleted
same as above, may be combined; the WebSocket may be closed after this message, but it's useful to tell a client that his account got removed, because otherwise it would try to-relogin due to invalid session and ultimately break with "unknown username", which is not very user-friendly and there's no better way to determine this situation otherwiseUse snake_case or CamelCase or whatever you want.
Of course, all of those are up to discussion and refinement.
The text was updated successfully, but these errors were encountered: