On 12 Feb 2015 14:00, "Christian Schudt" <christian.sch...@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 conversations. > 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 evolving it? > > Christian
