[Standards] MUC 2
dave at cridland.net
Thu Feb 12 16:19:00 UTC 2015
On 12 Feb 2015 14:00, "Christian Schudt" <christian.schudt at gmx.de> wrote:
> Dave, maybe could you (or somebody else) elaborate on the "shortcomings"
and the "different demands of things like buddycloud" you have discussed
for those who didn't attend the summit.
> Also what's so bad about multiple parties chatting via a third party chat
service (your 2nd use case)?
In the case of a private conversation between three people, it feels wrung
to introduce a fourth.
> For me one shortcoming of XEP-0045 is that there's no good concept for
the offline case of an occupant (member).
> E.g. you create a members-only room with three friends. They exchange
messages, while you are one week offline. You then enter the room and only
receive messages according to your "discussion history" request while
entering, let's say the last 25 messages. But missed most of the messages
your friends have exchanged, while you were absent.
> That's of course unfortunate, because you would expect to not miss any
Right, and this was discussed in detail at the summit. Presence and MUC are
going to be split. MAM is part of the solution here, as I'd the account
model based pubsub.
> It's like if my mail client would only request the last few mails from
this mailing list, when I start it and any older messages could only be
read in an archive via a browser, if available. (well, maybe this could be
solved with pubsub).
> Although I don't know the real shortcomings and demands you discussed
about, I imagine doing MUC with PubSub adds extra complexity. XEP-0045 is
already complex, XEP-0060 is even more complex and maintaining two very
different MUC approaches (from a technical point of view) is a burden for
any developer, while end users probably won't see many differences (e.g.
they don't care if their MUC is hosted by an traditional chat service or by
a PEP service).
Well, pubsub is actually simpler than MUC, since MUC is essentially an all
or nothing, whereas pubsub is a tiny core with lots of optional parts.
Secondly, I think that we do want to maintain basic protocol compatibility
with old MUC, so clients joining via presence we probably want to support,
and clients sending messages would be unchanged.
I'm reasonably confident that MUC 2 should be okay to implement on both
server and client. Luckily, clients won't have to change much, and we can
almost certainly keep full protocol compatibility.
> Isn't it possible to eliminate the shortcomings of XEP-0045 by just
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards