On 2014-03-05 12:48, Winfried Tilanus wrote:
> [..]
> Well, I *assumed* your MUC implementation did not support this.
>
> Assuming that, you can try to change your MUC implementation (leaving
> alone the question if a change to XEP-0045 is needed). But when you have
> to change your MUC implementation, you may consider to hook into the
> pubsub infrastructure: that infrastructure leaves much more room for
> creating data nodes for providing the data you need.
There's a huge difference in allowing existing protocol be used in more
expanded use cases (like requesting a room's member list) and adding an
entire protocol suite to an existing implementation.
Also, if I look at Christian's use case, he is simply trying to work on
the common multi-user chat protocol. I'd assume that backwards
compatibility with existing clients is at least preferred, if not
requirement. So re-using MUC makes a lot of sense.
And sure, if we were to start over, we might have built MUC on top of
the publish-subscribe protocols. The current MUC protocol has its warts
and dark corners, but a full-scale replacement (possibly on top of
pubsub) is simply not going to happen. And, contrary to popular belief,
pubsub is not the be-all and end-all of all things XMPP. At most, we can
'evolve' parts of the MUC protocol with backwards compatibility in mind.
And with that I made a bridge to my intended contribution to this thread
about bringing XEP-0045 to Final. I do see places of improvement to our
current protocol for MUC. I chatted with a few people on this in
Brussels and it might be useful to just jot it down here:
1) Redo the room join protocol with IQs. You'd simply send an IQ to the
room JID (as opposed to an occupant JID) and send presence there,
too. This basically gets you to a new-style mode.
2) Use opaque identifiers for the resource part of occupant JIDs.
3) Display names (nicks) are just one property of an occupant,
orthogonal to being in the room. It might that you could request a
display name when joining a room or that it is something you
register if you have an affilitation with the room. We could define
protocol for changing nicks. It might be that display names come
from your roster or occupant vCards.
I want to note that Google Talk's MUC support (before new Hangouts) did
something similar. Because of the way it handled directed presence and
how directed presence relates to current-MUC-join, this caused issues
with nick changes and other things.
The above might improve the brittleness of using presence for room
joins/unjoins. It would also allow for a mode where you are in the room,
receiving/sending messages, but not interact in the presence exchange.
Over the years I've seen several use cases that would benefit from that.
Nothing of the above would impede a move of XEP-0045 to Final, by the way.
--
ralphm
