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

Holger Weiß holger at zedat.fu-berlin.de
Wed May 6 15:31:08 UTC 2015

* Daniel Gultsch <daniel at gultsch.de> [2015-05-06 16:32]:
> 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>:
> > > > 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. [...] 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)

Yes, though clients will also have to tag MUC PMs (or add a <no-copy/>
hint or whatever) to take care of outgoing MUC PMs.  And once they do
that, there's the downside that in the above case where /A and /B are
joined using the same nick, /A will receive the incoming PMs but not the
outgoing PMs sent by /B.

You might consider this the least evil of the available options ...


More information about the Standards mailing list