XML Description

Requests  Responses

The schema document

Task 2 Alteration

An individual user may have a number of invitations sent to him, which he can ignore or act upon. Once a player successfully joins a table then all invitations maintained by that client are eliminated.

If a player has received a number of invitations, he may log out before acting on any of them. When the player logs back in, he will have no "memory" of the prior invitations. This decision was made to simplify the protocol and the server state. In this regard, invitations are "transient" structures. Naturally, if the server dies and is restarted, no invitations are retained.

The server should temporarily remember (for a specific table) the invitations that were tendered. When a client attempts to join an invitation-only table, the server should check the record and if that person was on the invitation list, then the join is to be allowed, otherwise it should be rejected. Once a table starts, all invitations are cleared from the server's info about the table. In any event, no invitations are persistent.

When the server receives the INVITE request, after acting upon it, it simply forwards that request along to the relevant client who will then act upon it by alerting the user about the invitation (in some low-bandwidth, non-intrusive way. Don't use a POP-UP!)

The following changes to the protocol have been made and logged.

Change Log

1. [Thu Apr 19 19:49:05 2012] PlayerResponse now has an optional admin (boolean) attribute for each player to declare whether that player is an admin.
2. [Thu Apr 19 19:18:29 2012] Added 'player' optional attribute to updateResponse that contains the player whose score is being updated. This is optional because you should be able to retrieve the appropriate information from the originator field of the Message request.
3. Thu Feb 16 21:50:32 2012] Added ban request from admin to ban a player from the system. If player is not currently logged in, no specific response generated. If player is logged in, server actively logs player out.
4. [Thu Feb 16 21:45:23 2012] Added updateResponse to be the response to the server for an update request sent to the server.
5. [Thu Feb 16 21:40:39 2012] Added finished attribute to update message which is a boolean (default=false) that is set to true when the client is sending the final update request to the server.
6. [Fri Feb 10 14:06:45 2012] Use public/private/byInvitation in the tableChoice element.

---

7. [Sun Feb 13 20:03:40 2011] Draft protocol released.
8. [Tue Feb 15 18:29:35 2011] Added rejectResponse to ensure the client can "unlatch" when it is waiting for a response to an earlier join.
9. [Tue Feb 15 18:33:45 2011] When the last player that has joined a table leaves, then no tableResponse is sent but rather tableEmpty.
10. [Wed Feb 16 13:29:02 2011] Added to output message two new attributes. The 'from' attribute is the player-id from which the message originated. if the 'system' attribute (a boolean) is true then the message originated from the system and no individual player.
11. [Wed Feb 16 13:35:43 2011] Added an 'inPlay' option to the tableChoice attribute of 'table'. Prior to this, it was open or closed.
12. [Thu Feb 17 13:37:56 2011] unregister was modified to eliminate player name and to require a hashed password to authenticate the request.
13. [Thu Feb 17 13:41:08 2011] playerInfo removes the 'player' attribute because the server detects the client from which request is coming. To prevent malicious password or name changes, this request demands the hashed password from the client.
14. [Thu Feb 17 13:53:32 2011] updated player to incorporate the children rating scheme, whereby a player may have multiple ratings. For now the categories are "solitaire","wordsteal" and "sudoku" (to be added).
15. [Thu Feb 17 20:14:49 2011] added an optional 'rating' attribute to the tag which appears within the tableResponse response message. Basically, this could be used to send to the client each player's rating for the selected game and then the client could disply this information with the table, should it so choose. Note this is optional.
16. [Thu Mar 3 21:33:11 2011] Eliminated player tag from turn requests because it was redundant.
17. [Sun Mar 6 20:22:33 2011] Modified turn so that the internal gameState children is entirely optional. This was done so Skip moves do not have to create a dummy gameState which doesn't actually change values.
18. [Tue Mar 8 10:54:40 2011] Eliminated player attribute from finish request because that can be retrieved by the server. Not yet sure if the game attribute needs to be there.
19. [Thu Mar 10 09:43:13 2011] Clarifying within the LEAVE description that a client can withdraw a request to join a table by issuing a LEAVE request for that same table. It is up to the server to process this properly.
20. [Mon Mar 14 14:01:33 2011] Added 'move' attribute to the gameResponse class to include moves made by players on that table. When the game initially starts, the optional move attribute should not be included (and it should be ignored if it is there by mistake). Thereafter, when move is included, it describes the state of the last player's move which will be consumed by the clients and 're-played' as it were. When a player chooses to skip his turn, then move will not be included.
21. [Wed Mar 16 15:17:20 2011] Finish request has been removed from the protocol. It is to be replaced with turn where its complete attribute is set to true or false.
22. [Mon Mar 28 23:19:25 2011] Fixed defect in "OPTIONS" that had 'closed' as the default value for the game attribute. This is now an optional attribute, but of course you can't leave it as optional forever...
23. [Fri Apr 1 17:14:32 2011] Note whenever a move is made by an opponent on the WordSteal game, the server must include the 'from' attribute with the GameResponse to reflect that player so the receiving client knows which user executed the move. This explicit declaration eliminates the implicit ordering issues we've been dealing with. This attribute is optional (as is move) because the first gameResponse has neither.