PBeM beyond email (was Scramble boards)

[Kevin Walker <kwalker@xmission.com>]

Here are my own crazy ideas about providing the option for graphical 
interfaces to PBeM.

(1) Extend PBeM to accept commands (and emit responses) via HTTP/CGI, 
telnet, or some other socket-based protocol.  For example, PBeM 
receives an HTTP request for the URL 
"http://www.gamerz.net/http_interface.cgi?command=twixt%20move%20
341%20kwalker%20my_password%20o9", PBeM does its usual routine for 
the command "twixt move 341 kwalker my_password o9", then sends back 
a "web page" (text/plain, not text/html) which is identical to what 
it would send in the body of an email message in response to that 
command.  Why would this be a Good Thing?  Because then others could 
write graphical client interfaces in their favorite language to make 
and receive PBeM moves for their favorite PBeM games.  Here's what 
the client would have to do when making a move: (a) interpret a mouse 
click as a game move, (b) construct the PBeM command (e.g. "twixt 
move 341 kwalker my_password o9", if I clicked at o9), (c) send an 
HTTP request as above, (d) receive the HTTP response, and (e) parse 
it too see whether the move was accepted.  To receive an opponent's 
move, the client would have to poll PBeM to see whether a move had 
been made on that board.

Advantages of crazy idea number (1): (a) very little work needs to be 
done on the PBeM server end -- the commands and responses are 
identical to what's already being sent/received via email; (b) 
flexible, open framework -- people could write clients in the 
language of their choice, for the games of their choice.

(1a) With a little extra work, PBeM could send a reply that is more 
easily machine readable (instead of the current text board 
representation plus recent move list).  This would save client 
authors the trouble of constructing complicated regexes to parse the 
boards.

(2) As an alternative to (1), someone could set up a separate server 
that monitors PBeM games via email.  (cf. 
http://www.math.lsu.edu/~wamelen/gamerz.html) This separate server 
could serve clients as in (1).  Advantages over (1): zero 
modifications needed to PBeM.  Disadvantages:  considerably more work 
to write the separate server.

(3) Write a real-time game server, which optionally interfaces with 
PBeM via (1) or (2) above.  (So the server would provide both 
real-time games and also correspondence games via PBeM.)  If this 
server used modular, open protocols, it would be feasible for various 
people to add games to the server.  If anyone is interested in 
collaborating on a project like this, please let me know.  I've 
already taken some initial steps in this direction: graphical game 
tree editors for Hex and Twixt, with Reversi and LoA underdevelopment 
(see http://www.xmission.com/~kwalker/jgame/).

--------------

Actually, I think (1) is a very practical and good idea -- not crazy 
at all.  I haven't done any programming for PBeM, but I am an 
experienced programmer, and I'd be happy to help implement this idea.

Kevin