On Mittwoch, 4. Oktober 2017 10:19:47 CEST Georg Lukas wrote: > [… snip: excellent summary of the issue …] > > Proposed Solutions > ================== > > All of the following change behavior and would need to be feature-coded > in the MUC/service caps: > > 1. Mandate different response codes to 0199 ping on the MUC JID (not on > the self-participant-JID), e.g. > 'not-acceptable' --> you are not joined > OK result --> you are joined > > 2. Create a new, explicit am-I-joined IQ that a client can send to the > MUC JID. > > 3. Create a new <presence> or <x> sub-element <rejoin-if-needed/>. > > After joining a MUC, a client would add that element to all subsequent > presence stanzas sent to the MUC (and would periodically send such > presence to check whether it is still joined). > > The MUC service would treat this presence as follows: > > If the client is joined: only reflect the presence to participants if it > is different from the last-reflected presence (to avoid the O(N²) > overhead). > > If the client is not joined: send the client a presence-unavailable to > let it know that it is going to rejoin (and so it can flush the > participant list), then send presence broadcast, (partial) MUC history, > subject, participant presence. > > The last solution is the most complex, but allows for a > single-round-trip rejoin if the client got desynchronized. > > Opinions please?
I like the third option. The best part is that <rejoin-if-needed/> will provide an acceptable experience with minimal effort in existing client implementations, given that the <presence unavailable/> from the MUC service has reasonable status codes (defining a new, additional status code to make this unavailable presence easy to detect by complying implementations seems also reasonable). For services, I imagine that implementing this is not much more than a check to make in the code which processes GC1.0 joins which then injects a <presence unavailable/> and hands the presence over to the MUC join code. I suggest to ensure that a proper message is included in the <presence unavailable/> stanza. Possible issues: * Password-protected MUCs? Would you have to send the password with each "ping" presence? If not, how would that work? (Possible workaround: send a <not-authorized/> presence error in response to the rejoin presence *after* the <presence unavailable/> and have the client re-send a join.) * History? Would you have to send the wanted amount of history in each of those ping presences? (Simply sending it would probably not be too bad, e.g. by embedding the timestamp of the last message seen from the MUC or so). Those issues would not exist with an explicit ping IQ, because the rejoin is a separate round-trip. Still I prefer the <presence/> thing, because I feel that the return-of-investment is the highest here (services and clients need to be touched anyways). kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
