[JDEV] Add-on support from Jabber protocol

[Jean Louis Seguineau]

Along the lines exposed by Thomas Charron, may I suggest that you extend the
existing jabber:iq:register to the client side to handle registration to
add-on (what you describe as session).

Rationale : if your product supports add-on, there should be some kind of
generic add-on manager embeded into the client. This add-on manager will be
responsible for registering internally what add-on is present on a given
machine, and will be able to answer the browse request made by other peer
clients. It should also answer the registration request by creating a
session id that would be used as a <thread> in further exchanges between
peer clients. These session ids should only be unique for the duration of
the session, and beween aggreed peers.

It is possible to extend the existing jabber:iq:register to register to a
given add-on. This namespace include a tag <key> that is used to return a
unique key identifying the registration process. This tag value will be used
as the session id.

A peer to peer client dialogue would look like this :

Client->Add-on manager (request for required registration information,
applies to all add-on types):

<iq type='get' id='uniquevalue' to='foo at bar.org/resource'
from='bar at foo.com'>
  <query xmlns='jabber:iq:register'/>
</iq>

Note the use of the resource in addressing the add-on enabled client to be
certain to get to that specific client.

Add-on manager ->Client:

<iq type='result' id='uniquevalue' from='foo at bar.org/resource'>
  <query xmlns="jabber:iq:register">
    <instructions>Some instructions to be displayed if
necessary.</instructions>
    <key>A1B2C3D4E5F6G7H8J9K0</key>
    <username/>
    <name/>
    <password/>
  </query>
</iq>


Client->Add-on manager :

<iq type="set" id="uniquevalue" to='foo at bar.org/resource'
from='bar at foo.com'>
  <query xmlns="jabber:iq:register">
    <key>A1B2C3D4E5F6G7H8J9K0</key>
    <username>foo</username>
    <password>secret</password>
    <name>chess</name>
  </query>
</iq>


Add-on manager ->Client:

<iq type='result' id='uniquevalue' from='foo at bar.org/resource'>
  <query xmlns="jabber:iq:register"/>
</iq>

The client will send the add-on it wants to subscribe to in the <name> tag,
and retain the value of the <key> tag tu use it as the <thread> tag in the
message element.
You can add any kind of sophistication by using the other tags like
<password>, <username>, aso to add further functionality to the add-on
manager.

The adventage of this method resides in only extending existing mechanisms,
without affecting either the server of traditional IM clients.

Regards

Jean-Louis Seguineau
CTO
Antepo - a World of Interactions
http://www.antepo.com


----- Original Message -----
> Message: 2
> From: "Ashvil" <ashvil at i3connect.net>
> To: <jdev at jabber.org>
> Date: Wed, 1 Aug 2001 20:07:19 +0530
> Subject: [JDEV] Add-on support from Jabber protocol
> Reply-To: jdev at jabber.org
>
> Based on the feedback we got from Thomas Charron on creating some open
> extensions to the Jabber protocol, we have a first draft on what we think
> would be needed for Magrathea.
>
> We need
> a) a way for the client to query what add-ons are installed
> b) a way to establish session to the add-on
> c) provide the communication envelope between the add-ons.
>
> Here is the proposal in PDF format.
> http://dev.i3connect.com/proposal.pdf
>
> I hope we can quickly create a simple wire protocol to support the above
> needs. We have tried to design the wire format in accordance with the
other
> jabber messages but we don't have the long history and expertise in
Jabber,
> you folks have. So your feedback is highly valued.
>
> Regards,
> Ashvil
>
>
> --__--__--
>
> Message: 3
> To: jdev at jabber.org
> Subject: RE: [JDEV] Add-on support from Jabber protocol
> Date: Wed, 01 Aug 2001 10:43:05 -0500 (CDT)
> From: Thomas Charron <tcharron at ductape.net>
> Cc: ashvil at i3connect.com, Vijay at i3connect.com
> Reply-To: jdev at jabber.org
>
>   Doc looks good.  Only a coupla syntax issues I can see here.  First,
> Browsing.  You guys are definatly 'getting it' as far as this is
concerned.
> Theres only a small isse with the response.  The 'get' is correct, but I
think
> I'd do this a little differently then you did.  The 'conversation' would
look
> more like this:
>
> <iq type='get' to='jid2'>
>   <user xmlns='jabber:iq:browse'/>
> </iq>
>
> <iq type='result' to='jid1' from='jid2'>
>   <user xmlns='jabber:iq:browse' jid='user at jid2'>
>     <user jid="user at server/home" type="client" name="Home Desktop"/>
>     <application jid="user at server/chess" type="i3connectchess"
name="Chess"/>
>   </user>
> </iq>
>
>   There are actually several ways to do this, but this would be easiest.
If
> you implemented a generic gaming protocol, for use by multiple games, it
could
> look like this:
>
> <iq type='get' to='jid2'>
>   <user xmlns='jabber:iq:browse'/>
> </iq>
>
> <iq type='result' to='jid1' from='jid2'>
>   <user xmlns='jabber:iq:browse' jid='user at jid2'>
>     <user jid="user at server/home" type="client" name="Home Desktop"/>
>     <application jid="user at server/chess" type="i3connectgame"
> name="ChessMasta"/>
>   </user>
> </iq>
>
> <iq type='get' to='user at server/chess'>
>   <user xmlns='jabber:iq:browse'/>
> </iq>
>
> <iq type='result' to='jid1' from='jid2'>
>   <application xmlns='jabber:iq:browse' jid="user at server/chess"
> type="i3connectgame" name="ChessMasta">
>     <ns>i3connect:games:chess</ns>
>     <ns>i3connect:games:checkers</ns>
>   </application>
> </iq>
>
>   Make sense?  The important thing is to remember to use xmlns to
designate
> tags outside of the scope of jabber:iq:browse.  While we're loose as far
as
> validation is concerned, it'd be nice to at least TRY to stay within the
> rules..  8-P
>
>   Now, as far as data is concerned, IQ isn't *really* the mechanism to do
this
> with.  The <message> tag is.  Perhaps use IQ to 'negotiate' a session, but
then
> use the <thread> tag within a message to handle a logical stream:
>
> <message id='i3Con_1' to='jid1' from='jid2'>
> <thread>Game19274</thread>
> <x xmlns='i3connect:games:chess>
>   <move From='D7' To='D5'>
> </x>
> </message>
>
>   Think of Info/Query as an RPC mechanism.  You make a call, and get a
> response.  There is no logical 'stream' beyond the response to a get/set.
> Messages, on the other hand, have threads, which logically group messages
> together.
>
>   You also may want to take into consideration message confirmation.
Using the
> message and thread tags, you can:
>
> A) Numerically keep track of messages associated with a game, ensuring you
> didn't miss anything
> B) Provide recipt messages, so ya don't have any 'moves' get lost.
> C) Log the logical progression of the game.
>
>   By providing valid recipt, you also gain the ability to play with games
being
> interupted, and provide for a game transport that keeps track of games FOR
you,
> allowing for non-interactive play, aka, users wouldn't have to BOTH be
online..
>
>   Anyway, overall, it looks really good, and is a good start to a decent
use of
> the protocol system.  Others onlist may disagree, if so, speak up, I'm not
> afraid to be called an idiot..  8-P
>
> ---
> Thomas Charron
> << Wanted: One decent sig >>
> << Preferably litle used  >>
>