[Standards-JIG] New version of chess game protocol
Michal 'vorner' Vaner
michal.vaner at kdemail.net
Tue Oct 24 08:33:45 UTC 2006
On Mon, Oct 23, 2006 at 02:22:55PM -0700, Robert B Quattlebaum, Jr. wrote:
> On Oct 18, 2006, at 1:57 PM, Michal 'vorner' Vaner wrote:
> >On Wed, Oct 18, 2006 at 12:30:29PM -0700, Robert B Quattlebaum, Jr.
> >>On Oct 5, 2006, at 6:26 AM, Michal vorner Vaner wrote:
> >>>On Wed, Oct 04, 2006 at 11:02:08AM -0700, Robert B Quattlebaum, Jr.
> >>>>* I would not consider the receipt of an unavailable presence as an
> >>>>automatic forfeit. What if I get temporarily disconnected?
> >>>But what if you get really disconnected? Will the session stuck here
> >>The client should pause the game until the other resource is again
> >>available. If a client sends a move in a message to another player
> >>but that player's client doesn't know what game it is talking about,
> >>perhaps an error stanza should be sent in return.
> >Well, but what if it does not reconnect? Will the game stay paused
> Um.. well.. yeah.. until the user closed it manually. I think this is
> perfectly reasonable behavior, but it is up to the client
> implementation to decide I suppose.
OK, then the game MAY terminate, maybe it is better. You are right, it
may be left up to the implementation (automatic AI bot would drop the
game, since it would not be ok for it to cumulate the games).
But, can the other side connect with different resource? For a
chess-only client, it would be IMHO better to get an automatic resource
from server than let the user configure it.
> >>>>* For cases where there are spectators, why not use a MUC room? We
> >>>>should try to take advantage of such facilities as much as
> >>>>It will make client implementation of this protocol more simple,
> >>>>thus more people will implement it. It is also more scalable for
> >>>>games with large numbers of spectators.
> >>>Hm, maybe because MUC does not support some things (iqs) and alters
> >>I'm not sure what you mean by "alters it".
> >I guess no-one said it may not modify the stanza it is routing. For
> >example, many of them modify the <presence/> stanzas. It may strip of
> >anything except <text/> part of the <message/> stanza. Or, it is how I
> >read the specs. (it does not say it is allowed either).
> Yes, a given implementation can do this, such as for an IRC gateway.
> But why the hell would you try to conduct a chess game over an IRC
> gateway anyway?
> In my experience, true jabber MUC implementations only add
> information to the stanza, and don't generally strip. Even if there
> were some implementations which did, I still think that it would be a
> perfectly acceptable choice.
So, if they can do it, we can not expect them not to do so. At last some
other feature to the usual implementation could be added (like
http://jabber.org/protocol/muc#no-strip to the disco), so clients can find the
muc all by themselfs.
> >>MUC does not seem to explicitly define the forwarding of IQs (perhaps
> >>it should specify it as an optional part of the spec), but it seems
> >>that some implementations do this anyway(I noticed icons working in
> >>anonymous MUC rooms with pandion). Either way, I don't think that the
> >>forwarding of <iq> stanzas is a absolute requirement for this
> >No, not this protocol exactly. But there may be a game in the future
> >that would need them.
> I do not think that we should be creating this bloat of a protocol to
> try to encompass every game we can think of.
> I'm really thinking that we should have two types of games: ones that
> need 'referees' (ie: a game server for maintaining the private game
> state), and those which don't. Trying to have one protocol is
> sounding less and less desirable.
> The pieces are already in place to have both private and public chess
> games in XMPP architecture. We need to make sure that we leverage that.
OK, which would return the chess game back to the beginning without game
sessions and add a possibility to multicast the moves over MUC?
So, if I get you right, you say there is no need for game sessions but
for some kind of way to multicast over MUC XEP (still, what to do with
<iq/>s and so, if they are forbidden to use, allowed, and how).
> >And no, it is not a show stopper. But I do not like the way it would
> >work. It is one big workaround that could bring many problems in the
> This is NOT a workaround. This is perfectly appropriate use of a pre-
> existing protocol.
Well, using multicast component for multicasting seems more natural and
right to me than using MUC.
And as I said, the MUC would be OK for chess, but if we want all the
games to behave more or less in the same way, then MUC will make lots of
problems in some games. (As I said, you know number of participants, for
the first thing, you need to keep ordinary clients out of the MUC
somehow, which makes it harder to connect for game clients..)
> >The game protocol could be built on top of PEP, however, that would be
> >probably more complicated.
> I think that would be a bad idea, especially since MUC is a perfectly
> good solution.
So, lets suppose MUC is the solution for a moment. You get visitors for
free, you have admin, you have multicasting of <message/> stanzas and
you have chat between the people. How do you propose to sort out these
problems: (present in the easy chess thing)
*) Allowing in only chess clients. Password is not nice way, since you
need to let everyone know, so you can not just create the room and wait,
is someone connects.
*) Choose the right MUC component automatically. I know you would never
try to play chess over IRC gateway, but what if there is a user, who
does not see the difference? The client should choose it automatically
if possible. How does the client recognize the MUC is suitable?
*) If you wanted a game with referee, how would you do it? You would add
referee to the room and he would just kick anyone who made an illegal
move? Or retract the moves somehow? Or you would need to specify
completely different protocol for the game with referee?
Hello, this is an extension to the famous signature virus, called spymail.
Could you please copy me into your signature and send back what you were
doing last night between 10pm and 3am?
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the Standards