[Standards] Multi-client operation and read-until-X markers

Holger Weiß holger at zedat.fu-berlin.de
Wed May 6 14:12:48 UTC 2015

* Daniel Gultsch <daniel at gultsch.de> [2015-05-05 17:13]:
> 2015-05-05 16:30 GMT+02:00 Georg Lukas <georg at op-co.de>:
> > One possible workaround would be to mark all MUC PMs, like it is done by
> > prosody: http://hg.prosody.im/trunk/rev/09151d26560a
> > Then, a client could use that information to determine if it just
> > received a MUC PM from a MUC it is not joined into.
> This sounds like a very simple but usable solution.
> I'm going to implement this in Conversations tomorrow.
> I though about this earlier but never got around to actually write the code
> for this.
> I hope that other servers will jump on board with this quickly.

ejabberd now tags MUC PMs in the same way.¹

> > Another issue: If both /A and /B are joined to the MUC using the same
> > nickname, the question arises whether the MUC component should copy a
> > PM to both resources, or send the PM to one and a carbon of it to the
> > other (and how the priority/routing is supposed to be handled in that
> > case).
> Defenitly not both like it is done currently. (Or has been done?)

Sending just one copy makes sense if the clients receive carbon copies
anyway; but if they don't, it might go against expectation that delivery
for /A now depends on whether/how /B joined the same room. (Then again,
the routing behavior when multiple clients are used without carbons
probably goes against the expectations of most users anyway.)


¹ https://github.com/processone/ejabberd/commit/7297b23508

More information about the Standards mailing list