On Oct 23, 2007, at 4:31 AM, Tomasz Sterna wrote:
Dnia 21-10-2007, N o godzinie 15:42 -0400, James Tomson pisze:
In addition to 'broadcast invitations', we have added extensions to
allow the inviter to cancel its pending invitations at any time, or
have the room do it on their behalf after a specified timeout. For
the sake of brevity I won't stanza-spam these case unless there is
interest :D
[snip]
I think, that we should document best practices to do so, and
standardize the extensions you had described, in sake of
interoperability.
So please, do share. :-) It's the reason this list was created
for. :-)
Happy to :D
This is how we specify a timeout for invites -
firstwitch sends 'broadcast' invitation to thirdwitch, set to expire
in half an hour:
--
<message from='[EMAIL PROTECTED]/desktop'
to='[EMAIL PROTECTED]'
type='groupchat'>
<x xmlns='http://jabber.org/protocol/muc#user'
xmlns:wmi='wimba:muc:invite'>
<invite to='[EMAIL PROTECTED]'
wmi:ttl='1800'/>
</x>
</message>
--
thirdwitch receives invitation from room, with ttl and timestamp:
--
<message from='[EMAIL PROTECTED]'
to='[EMAIL PROTECTED]'
type='groupchat'>
<x xmlns='http://jabber.org/protocol/muc#user'
xmlns:wmi='wimba:muc:invite'>
<invite from='[EMAIL PROTECTED]/desktop'
wmi:timestamp='2007-10-31T23:52:22'
wmi:ttl='1800'/>
</x>
</message>
--
After a half hour passes with no response (thirdwitch does not join
the room, or send decline), the room will send an invitation
cancelation to thirdwitch:
note: timeout flag element
--
<message from='[EMAIL PROTECTED]'
to='[EMAIL PROTECTED]'
type='groupchat'>
<x xmlns='wimba:muc:invite'>
<cancel-invite from='[EMAIL PROTECTED]/desktop'>
<timeout/>
</cancel-invite>
</x>
</message>
--
room also 'broadcasts' this cancelation to the occupants of darkcave
(message to secondwitch shown):
--
<message from='[EMAIL PROTECTED]'
to='[EMAIL PROTECTED]'
type='groupchat'>
<x xmlns='http://jabber.org/protocol/muc#user'
xmlns:wmi='wimba:muc:invite'>
<item affiliation='owner'
nick='firstwitch'
jid='[EMAIL PROTECTED]/desktop'
role='moderator'/>
<wmi:cancel-invite to='[EMAIL PROTECTED]>
<timeout/>
</wmi:cancel-invite>
</x>
</message>
--
A policy we've set up is that when the instant-room is destroyed
(last occupant has left), the room will send <cancel-invite/>
messages to all jids with pending invites automatically.
In another use case, firstwitch cancels her invitation to thirdwitch
explicitly:
--
<message from='[EMAIL PROTECTED]/desktop'
to='[EMAIL PROTECTED]'
type='groupchat'>
<x xmlns:wmi='wimba:muc:invite'>
<cancel-invite to='[EMAIL PROTECTED]'>
<reason>bah!</reason>
</cancel-invite>
</x>
</message>
--
then the room will 'broadcasts' this cancelation as a normal
groupchat message to the occupants of darkcave:
--
<message from='[EMAIL PROTECTED]/firstwitch'
to='[EMAIL PROTECTED]/laptop'
type='groupchat'>
<x xmlns:wmi='wimba:muc:invite'>
<cancel-invite to='[EMAIL PROTECTED]>
<reason>bah!</reason>
</cancel-invite>
</x>
</message>
--
The difference here is that this explicit cancelation is from
firstwitch's room resource, and therefore lacks the muc#user <item/>.
To that end, when a new occupant joins, this is what the 'pending
invites push' message, from the room, contains as many <x
xmlns='http://jabber.org/protocol/muc#user' /> elements with items,
and invite child elements, as there are distinct inviters with
pending invitations.
This last point may benefit from a stanza example, but I am currently
out of witches :D
-James
----
james at wimba dot com
