On Aug 3, 2007, at 3:10 AM, Robin Redeker wrote:
Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ?
That would still be useful to store non-autmatically-joined MUCs I
guess?
Also that XEP offers also a way to auto-join MUCs.
The more we talked about this around the office, the more we thought
we only needed two things to make this work for our use cases.
1) A new MUC role which effectively the opposite of visitor. Of
course, on the bar napkin, this got written as "rotisiv". :) A
rotisiv can potentially speak (broadcasting to all of the members of
the room), but can't see any of the messages that are broadcast to
the room. As well, rotisivs get presence from all of the
participants and moderators of the room, but nobody receives the
rotisiv's presence from the room. Obviously, an implementation might
want ACLs to specify who can be a rotisiv for a given room.
2) An addition to xep-48 that gives a little more meta-data.
<iq type='set' id='2'>
<query xmlns='jabber:iq:private'>
<storage xmlns='storage:bookmarks'>
<conference name='Council of Oberon'
autojoin='true'
jid='[EMAIL PROTECTED]'>
<group xmlns='' role='rotisiv'/>
</conference>
</storage>
</query>
</iq>
Just as for normal MUC, the client sends a separate presence stanza
to each group they are a participant in or moderator of, whenever the
user changes presence; this allows a client can use its existing MUC
and bookmarks implementation to do whatever UI they want, manage
which groups they appear online to, and the like. In this case,
pushing a small amount of complexity down to the client (which the
client probably already has anyway) leads to a vast simplification in
the server implementation. It's very apparent which presence is
group-related for clients that want to do special UIs, and existing
clients that haven't implemented the new feature get to participate
in groups.
--
Joe Hildebrand
