I worked on this for a bit longer than I thought I was going to, but I've also got a sturdier product than I was expecting to have at this stage.
I've pushed all my work to Github; here is a permalink to the exact point I'm at currently, regardless of what future work I do.
So, let's see what it can do! We'll run
./server.py in one tmux window and
telnet localhost 8001 in two others.
./server.py in the left-hand frame.
When I run
telnet localhost 8001 in the upper-right frame, the server outputs a debug message to let me know that an anonymous user has connected. The user gets prompted for their name, after the usual Telnet guff.
I enter my name, and the server records that my connection has been 'registered'. It also lets the user know how many people are online currently.
I can now type 'commands', and they'll be passed along to my
gamesession's eval-loop: of course, this isn't implemented yet, so for now it just gives us some server output to let us know it's been pushed through the queue and handled on the other end.
I'm creating a new connection to the server in the lower-right tmux window, using the same method as before.
Again, as before, I enter a username for myself (I forgot to add underscores into the regex for valid usernames!). Notice that all the username validation is server-side, and that the "people online" counter has incremented.
This is showing us a potential slip-up: even though the
gamesessions for "bede" and "secondbede" are completely separate, they're using the same
call() function. We'll have to be careful to make that
call() call (heh) more specific: possibly by storing the game-state in the
gamesession, and passing it to
call() every time; or possibly by making
call() a method of
gamesession. (That second one would be more convenient, but
call() would have to be renamed to something like
call_cmd()- reasoning-wise, it's not
gamesession that's being called, it's the command from the
"bede" hasn't lost the right to request command-evaluation just because there's another player online.
Closing the first connection client-side.
Closing the second connection client-side.
Shutting the server down with C-c. This is strange - even with a "GameSession.running" signal value, it seemed like C-c had no effect, as if a thread was still running. Setting
thread_name.daemon = True seemed to fix the problem, and accordingly it's in the current version, but I'm not quite sure what it does - let's hope it doesn't just leave threads running in the background, as the name seems to suggest.