* Daniel Gultsch <dan...@gultsch.de> [2015-05-06 16:32]: > 2015-05-06 16:12 GMT+02:00 Holger Weiß <hol...@zedat.fu-berlin.de>: > > * Daniel Gultsch <dan...@gultsch.de> [2015-05-05 17:13]: > > > 2015-05-05 16:30 GMT+02:00 Georg Lukas <ge...@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 ... Holger
