Games will be indentified by gamename/username pairs. This will allow
better interoperability with dgamelaunch.
Polling clients are no longer supported; the code remnants need to be
removed. The reaper() function will likely crash. Unexpectedly, the
WebSocket client still works well enough to play. Watching and listing
current games are probably broken.
watcher.c is a subprocess which uses inotify to watch the inprogress
directories. A C program is used because node's fs.watch() can't tell
the difference between creation and deletion.
The daemon module doesn't include chroot() anymore, so a replacement
is needed. Detaching a daemon keeps getting harder to do in Node, so
some setup has been moved into a shell script.
User information can be retrieved at /uinfo?key=<login key>&<prop>.
The only property currently retrievable is email; eventually these will
also be settable via POST.
rlgwebd sets TERM to xterm-256color, which uses CSI H CSI 2J to clear
the screen. The description of srogue had been CSI H CSI J, which is
the sequence for screen.
Server-side, have gamemux 'end' events include the name and game, so
they can be sent to WebSockets connected to /status. This means a
WebSocket client only needs to update its choice list when it gets a
begin or end message with its own username. So it only needs to check
/pstatus/<name> at those times and can stop polling.
WebSocket sessions should not be taken over, and polling sessions are
not yet convertible to WebSockets. Eventually the current method of
taking over via Player#reset() should be replaced with autosaving the
game, which will always work.
Delete some TermSession code left over from the first attempt at
Websockets. Also don't bother logging the disconnection of watchers
after the game has ended.
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.
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.
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.
