[Standards-JIG] Invitation to use XMPP based game from Instant Messaging Application.

Michal vorner Vaner michal.vaner at kdemail.net
Wed Aug 23 15:50:28 CDT 2006


On Wed, Aug 23, 2006 at 05:17:54PM -0400, Tim Hentenaar wrote:
> Op wo, 23-08-2006 te 20:37 +0200, schreef Michal vorner Vaner:
> 
> > Well, why jingle? :-O I guess chess game is neither time nor data amount
> > critical to use jingle for it. The game is simply over the XMPP stream,
> > this is just about not running the game all the time and still let other
> > know "I would not say no to a game".
> 
> Now that I think more about it, Jingle does in fact seem like too much overhead, even for basic signaling. 
> 
> We could use a Stream Initiation profile for session control and negociation.
> 
> For games that stream large amounts of data, or don't/won't support
> XMPP, one could develop some sort of tunneling through the client (e.g.
> client initates game session by negociating over XMPP, clients connect,
> etc.) Such that the app dosen't have to be XMPP-aware in order to work.
> The data in this case would be better sent OOB IMHO. Prehaps something
> like:
> 
> <!-- SI Response -->
> <query xmlns='jabber:iq:oob' sid='a0'>
>     <url>doom://127.0.0.1:666/</url> <!-- game short name :// ip [: port] / [other information to pass] -->
>  </query>
> 
> Or even simply a uri of "game://ip:port/game_name=doom".

Well, I would put that to separate JEP. Actually, I fear that would be
so hard to code it won't work anyway, but it is only estimation.

However, for such tunneling, Jingle is probably the thing to go.

> For chess, something like what Robert's "back-o-the-napkin" protocol
> shows would seem ideal.

Yes, that is very similar to my protocol, which I'm just writing down.
It has a little different element names and has different negotiation,
but the idea is the same.

> I have many more ideas in regards to such a setup, I just need to sort
> them out. ;) 
> 
> > > It would also definitely be intersting to also be able to use something
> > > like PubSub so that any number of users could subscribe to, and watch a
> > > chess game if the app were Jabber-aware :P
> > 
> > Hm, all these pubsub things have one big problem: I did not yet met a
> > server supporting PEP and PubSub itself is heavilly overcomplicated for
> > such a simple thing.
> 
> I believe ejabberd support pubsub, but I haven't tested it yet. 

Hm, I think you need different support for PEP than PubSub. Actually, I
did not read these JEPs, but the PubSub one is rather large one, so I
guess it will be complicated.

And the problem is not just server software supporting it, but as well
see the service on real servers.

> Well, it could be done without something as monsterous as pubsub (ex:
> having the capacity to have n number of people 'watching' a 
> game session, and have the relevant packets broadcast to all listeners.
> It would certainly be trivial to implement.

Is not the PEP aimed for that? Just have to wait for servers to support
PEP..

> e.g.:
> 
> <x xmlns="jabber:x:game:chess">
> 	<propose action="watch" />
> </x>
> 
> <!-- ... Accept / Deny ... etc. -->
> 
> 

-- 
Fragile. Do not turn upside down.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20060823/0ade6049/attachment.pgp


More information about the Standards-JIG mailing list