[JDEV] question regarding jabber:x:conference

[Keith Minkler]

from implementing the draft-proto for conferencing in IRC transport, I ran
into this problem.. turns out that the document is just a little unclear
on certain aspects of operation.. lemmi clear everything up..

> The thing that I've never understood is what happens when someone wants 
> to leave a group... what would seem to happen is that their final nick 
> will remain tied up and also everytime someone logs in their (now 
> unused) member information will continue to be iq/set out to all new 
> group members.

When the group gets the unavailable presence from the user, they are considered
gone from the group. each person in the group will get a iq:browse push from the
group, for that user:

<user jid="group at conference/a34de.." type="remove"/>

this tells the group that they are gone, (and the nick is freed)

> The two issues as i see it are:
> 1. how does a user indicate that they are leaving for good
> 2. how does the transport tell all users that the member is leaving for good

see above..

> My thoughts are this:
> - when a presence/unavailable is retrieved from a group member he is 
> considered to have left for good (unless the are 'registered').

well.. current conference does not allow any sort of registration for nicks..
if you are writing a module that uses a nick registration, i suggest you simply
use the "conflict" error code (don't know the # offhand) to tell someone that
they cannot have that nick... that should take care of ever'thing..

> - to indicate a member has gone for good to other members send out a 
> jabber:iq:browse where the user tag has no name attribute _or_ (if 
> jabber:iq:browse tags are a complete roster) just send a new complete 
> roster out.

the remove attribute is already used in roster pushes, and this is how the
iq:browse for conferencing is done, with pushes.. the concept is basically,
the user will get one full roster, or browse, then, if they have sent presence
to the jid, they will receive "updates" as type='set' these are the pushes.
the client should take them only as updates to the initial result, never as
a full roster/browse.  only the type='result' will be a full set. and result
should only ever be sent in responce to a type='get'

<snip/>
> Hope that makes sense, I'm pleased that the jabber:iq:conference 
> protocol has been proposed we needed it.

mind you that this protocol is already in effect... conference.jabber.org is
using this protocol to serve up groupchats (in addition to the 1.0 presence
style protocl), and irc.jabber.org, the IRC transport is using this protocol 
exclusivly.  It's a good change IMHO, and fixes all the problems that we had
with the "1.2" groupchat protocol. and the "1.0" protocol drawbacks.


Keith Minkler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010207/9e470785/attachment-0002.pgp>