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)? 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. 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). Isn't it possible to eliminate the shortcomings of XEP-0045 by just evolving it? Christian
