cardstories part 3: create and invite, client side

The create and invite functions of the JavaScript client were implemented and tested. The authentication methods specified so that it is friendly to social network integration.

create and invite

The architecture of the JavaScript client was implement as a single JQuery plugin with two arguments as called in the example:

$('.cardstories').cardstories($.query.get('player_id'), $.query.get('game_id'));

The HTML to which the plugin is applied is divided according to the state of the game: one div for each state with a class of the form cardstories_STATE. The invitation state is further divided in three div: one for the owner of the game, another for a visitor and the last one for the registered player to pick a card.
If the game_id parameter is missing, the plugin will display cards and an input box to enter the sentence.
The implemented functions are tested. They can also be tried manually but the interface is still very crude.

jslint

Although jslint.com provides an interactive way to check JavaScript code, it is more convenient to use the command line:

$ jslint static/js/jquery.cardstories.js
jslint: line 101 character 96: Expected ')' and instead saw '}'.

Unfortunately it is not yet packaged for debian The alternative is to compile it from sources, using the version found (but not installed) in the jscoverage package:

apt-get source jscoverage
cd jscoverage*
./configure
make install

player identification

This has not yet been implemented but it is described as if it was, so that it can be used as specifications.
When a player starts the client (i.e. the JavaScript client) it looks for the CARDSTORIES cookie. If it is not found, a SHA1 signature is calculated and stored in the CARDSTORIES cookie. The SHA1 value is used to identify the user : its identity is bound to the web browser and can be transferred to another navigator by copying it.
Server side, a table maps the SHA1 sum into an integer that can conveniently be used for indexing. This is done in the site.py source by remapping the player_id and owner_id arguments before they are handled by the service.py.

        d.addCallback(self.auth_preprocess, request)
        d.addCallback(self.handle, request)

The self.handle returns the JSON structure that is to be sent to the JavaScript client. It needs to be processed to replace internal identifiers back to their external counterpart by the self.auth_postprocess function:

        d.addCallback(self.auth_preprocess, request)
        d.addCallback(self.handle, request)
       d.addCallback(self.auth_postprocess, request)

If the game is to be included in a social network, the authentication module implementation will have to be replaced to verify the user identity. Client side, the player_id and owner_id will be set with values from the authentication namespace of the social network.

The same functionality could also be implemented via a reverse proxy in front of the Twisted/Python daemon. Such a daemon would need to know the structure of the incoming parameters and the outgoing JSON structure, but it could be completely transparent to the the Twisted/Python daemon.