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

Daniel Gultsch daniel at gultsch.de
Wed May 6 14:32:54 UTC 2015

2015-05-06 16:12 GMT+02:00 Holger Weiß <holger at zedat.fu-berlin.de>:

> * 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.)

Thought about this for a while and I think MUC PMs should not be carbon
copied at all. Depending on the MUC implementation I'm probably not even
allowed to actually answer if I'm not logged into the same room. [citation
Not carbon copying is -  if you think about it - the only way to avoid
duplicate messages. Because having the MUC compenent sending out only one
PM even though the client is logged in with two resources doesn't make
sense either and will become unpredictable.

And with the stanza tagging mentioned above it will be fairly easy for
mod_carbon to detect a MUC PM (and not copy it as a result)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150506/23181163/attachment.html>

More information about the Standards mailing list