> On 4 Oct 2017, at 16:41, Jonas Wielicki <[email protected]> wrote: > > On Mittwoch, 4. Oktober 2017 16:08:43 CEST Kevin Smith wrote: >>> On 4 Oct 2017, at 14:07, Georg Lukas <[email protected]> wrote: >>> >>> Hi Kev, >>> >>> * Kevin Smith <[email protected]> [2017-10-04 11:43]: >>>> Thanks for the write-up. I agree this is a problem worth solving. >>> >>> Thanks for the feedback! >>> >>>> I think (3) seems like it has nice properties in terms of a single >>>> round-trip, but I think (2) is the preferable option in practice. It’s >>>> simple to implement for everyone (3 is quite complex) [...] >>> >>> I agree that a new IQ (2) is trivial to implement, but I'm not sure if >>> there is significant complexity in the (3) approach - as Jonas wrote, it >>> just another way to re-synchronize a client, something that should >>> already happen by means of a regular MUC join presence, plus an injected >>> presence to the initiating client. >>> >>> On the client side, the number of self-ping implementing clients is very >>> low currently, and those implementations are complex already, if they >>> use a 0199 + rejoin combo. The benefit of (2) would be that clients can >>> have a simple switch for backward-compatible participant-JID-ping vs. >>> modern MUC-JID-presence-check IQ, and reuse the actual timeout & re-join >>> logic. However, if a client developer is sufficiently motivated to add >>> self-ping now, a proper solution might be an additional motivation >>> boost. >> >> I think the locality of (2) makes it easier. With (3) the thing that >> triggers the resync is probably a different part of your application (I >> would assume in most cases it’s part of a presence wrapper for >> redistributing presence to all directed recipients), which means changing >> the dependency tree of presence changing. > > I had not considered that. In that light, I see your point. Even though the > MUC code would have to tell the Presence Distributor that it has to > distribute > presence to the MUC anyways. So it could also tell it to distribute presence > + > <rejoin-if-needed/>.
Not quite as simple as that, because every rejoin-if-needed needs to be able to do a resync based on the last stanza received from the MUC. It’s do-able, obviously, but this is all getting quite nasty. >> OTOH, (2) simply requires the MUC >> code to send an iq, which is presumably straightforward for the majority of >> implementations. >> >> (3) is possible, of course, it’s all code, but the complexity of the change >> is *vastly* higher, at least for our client design, than (2). > > I don’t think it is "vastly" higher in the general case. Simply sending > <presence><rejoin-if-needed/></presence> instead of IQ, and deal with the > unavailable presence when it comes (you need handling for those anyways). I think you’re talking about needing much more than just rejoin-if-needed, you’re needing the payloads it carries. >> I think >> that “presence things with magic side effects” is one of the problems we >> have with MUC, so adding more such things isn’t what I’d choose when >> addressing this. > > I wholeheartedly agree with the spirit of that. This is a bad feeling I have > with (3), too. But (2) doesn’t solve the GC1.0 join issue (while (3) can, > because it depends on a feature var and adds a new child element to the > presence): if one sends presence updates while desynced from a MUC, one will > suffer a partial rejoin due to the Group Chat 1.0 legacy cruft. > > I thus think that bolting on top of the already existing "presence things > with > magic side effects" is the only way out of this. But I might be overlooking > something---please let me know if. I suspect we can sort out a way to resolve this without quite as much complexity as 3. Georg’s started a worthwhile discussion here, but I’m sure these aren’t the only 3 options we can consider. >>>> As it’s a sticking plaster, and we’re trying to fix things properly, >>>> going with a sticking plaster iq seems ok to me (as is more likely to >>>> get the needed wide deployment). >>> >>> I'm not sure what you mean by "fix things properly" - MIX? Even if a >>> plethora of MIX implementations should magically appear overnight, I'm >>> sure we'll stick with MUC for a long time (though hopefully not as long >>> as with GC1.0 now). >> >> Yes, missing words, sorry. ‘fix things properly…with MIX’. And you’re right >> that we’re a long way off MIX-only, but I don’t think that changes my >> opinion here. > > Yeah ... sorry, I like the idea of MIX, but I don’t see MUC going away > anytime > soon, especially since it maps so much better to IRC than MIX will, and > gateways are a thing. I think there’s significant wrong here, but It’s not the meat of the thread, so let’s let the “We’re not ready to MIX everywhere” bit go for the moment. /K
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
