I'd thought using the DOM_VK_ names was a good idea. Symbolic names
ought to be more portable than opaque numeric constants. Foolish me,
expecting things to be sane.
Keys now work with FF15 and Chrome 17.
The ajaxterm state machine assumed data appears in response to user
actions, which is not true when watching. It now uses different sets
of parameters for playing and watching.
It is now possible to watch games currently being played through
RLG-Web, but not dgamelaunch. Also, there are some deficiencies, like
getting chaos until an absolute cursor addressing happens.
Split the TermSession class into the new TermSession, which handles the
PTY, and client classes, which handle HTTP sessions. These are Player
and Watcher. This allows multiple watchers per game, and other
improvements.
Don't print a debug message for some control sequences that technically
are unimplemented, but would just put the terminal into the only mode
yet implemented. CSI 4l and CSI ?7h are like this.
Add a TermSession.sendq flag that indicates whether a type q message
has been sent to the client. Don't immediately destroy the TermSession
on child exit if the message hasn't been sent.
This is an ugly hack until the TermSession class is separated into an
EventEmitter to handle the PTY and a listening object that handles
communication with the client. That will also allow other clients to
watch the game.
The RLG-Web client was failing to realize the game was over, because
a test was checking against the entire response instead of the proper
field in the response.
Separate things like checking for games in progress, starting a new
game, and figuring out where the lockfile and ttyrec should go. This
allows e.g. the games-in-progress check to be used to create status
messages. It also keeps the argument list for the TermSession
constructor to a sensible size.
The user now logs in with a username and password, receiving a token
which is then used for any actions requiring authentication. Starting
a game is one such action. Games use a different set of id keys.
This allows users to supply their passwords once and then play any
number of successive games. Also, newly registered users do not need
to supply their passwords again.
For roguelike games, most output will directly result from and follow
immediately after input from the user. In other situations, data
should not be expected.
The RLG-Web server now forks off, writes to a logfile, and reads from a
control socket. Unfortunately it can't handle the problem of another
rlgwebd process already running. Maybe a lockfile would help.
The RLG-Web server can now be controlled with commands sent to stdin.
Currently, the only one implemented is "quit". Some improvements to
the shutdown process were also made.
