REST and games don't mix

i dont think the chess example makes too much sense. all you need to send along is the current board position, whether you have castled, and whether pawns have en passented. There is no "wait for response", it is part of the response back when you post the message. When you post a web form, you reload a page. You could easily create a RESTFUL chess game. the idea is simply that the local state is not stored on on server instance, so that the request has enough information to be transfered to another server, or balanced in anyway.

The chess analogy up top was assuming that the game doesn't persist in anyway. If it is being stored in a database, you don't need any game state being sent along (you could as you say, just send deltas). This would be just updating an object in the database which is still RESTful.

Thanks for your feedback!
Let me put it in a more succinct way, that didn't quite fit in the corporate version:
"I think COMET sucks for real-time interaction" :-)

heh it's funny that you mention this. I've been using Web Sockets for a while waiting for binary protocols to get added (using a 7-bit binary encoding in UTF-8 isn't the same :P). Also I will point out that you can drive how the web works fairly easily. I've had the standard changed in the past by my feedback and talking to the editors and implementers is fairly trivial. Hixie (Ian) used to edit the Web Socket protocol standard, but a new guy controls it now (Dave? Doug? Forgot his name). He's in the IRC channel (irc.w3.org 6665) along with all of the other editors if you want to push change. (I'm currently waiting on some canvas issues I submitted five days ago to get added into the standard >_>)

I completely agree with your article though. Even with the most optimal comet server I still had a little under 100 bytes of overhead per "packet" which ate up a lot of bandwidth. There's a huge difference using Web Sockets. It was also much less code to create the standard compliant socket server.