Is this able to create multiuser (more than 2 users) applictions?

1 view
Skip to first unread message

sgtpep

unread,
May 29, 2009, 5:58:01 AM5/29/09
to Realtime Gadgets
Hi there!
Is this able to create multiuser (more than 2 users) applictions (for
example, 4-player game)? Does anyone know is this can be aproached
with moving logic to server side?

moi...@google.com

unread,
May 29, 2009, 9:47:54 AM5/29/09
to Realtime Gadgets
Hi! There's not a direct way to do this right now (you can't be in a
multi-user chat and send an application to it); however, you could
write an XMPP bot that multiple people join a conversation with that
distributes state change messages.

The XMPP format we're using for this hasn't been submitted as a XEP
(yet) but if you're interested in this path let me know and I can show
you examples of how state change messages are passed around.

Thanks!

-Moishe

Moishe Lettvin

unread,
May 29, 2009, 4:41:28 PM5/29/09
to sgtpep, realtime...@googlegroups.com
In brief, we use <message> stanzas to pass shared state data between endpoints. First we send an invite element like so:

<message from='al...@host.com' to='b...@host.com'>
  <app:invite app:url='http://example.com/gadget.xml' app:id='1' xmlns:app='google:application'/>
</message>

This tells the other endpoint to get ready to set up an instance of gadget.xml.

Then, either endpoint can send <message> stanzas to update the shared state like so:

<message from='al...@host.com' to='b...@host.com'>
  <app:state app:url='http://example.com/gadget.xml' app:id='1' xmlns:app='google:application'>
    {foo: 'bar', baz: 'sna'}
  </app:state>
</message>

The text of the app:state element will be parsed as JSON and sent to the state change handler as an object.

As a heads-up, in the next server push, the invite element will change to have a "type" attribute which indicates an invitation, an accept, or a decline. This gives the invitee a chance to decline an application if they don't want it.

So the flow will be:

Alice sends bob an invitation:

<message from='al...@host.com' to='b...@host.com'>
  <app:invite app:url='http://example.com/gadget.xml' app:id='1' type='invite' xmlns:app='google:application'/>
</message>

Bob accepts:

<message from='b...@host.com' to='al...@host.com'>
  <app:invite app:url='http://example.com/gadget.xml' app:id='1' type='accept' xmlns:app='google:application'/>
</message>

And then either endpoint can start sending state updates:

<message from='al...@host.com' to='b...@host.com'>
  <app:state app:url='http://example.com/gadget.xml' app:id='1' xmlns:app='google:application'>
    {foo: 'bar', baz: 'sna'}
  </app:state>
</message>

State updates before the invitee sends the 'accept' stanza are ignored.

To re-iterate, this is pre-XEP and subject to change. Any feedback would be greatly appreciated! Looking forward to seeing a bot based on this.

Thanks-

-Moishe

2009/5/29 sgtpep <danil...@gmail.com>
Yes, using XMPP bot can make this possible.
It would be very useful to know your XMPP format.
I'm highly interested in working with "more than 2 users" because I
want to create simple turn-based strategy. I think, it could be fun to
play with few more players.
Reply all
Reply to author
Forward
0 new messages