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/>. > 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). The only issue (which can be solved in the protocol level) is that the MUC code needs to know the presence state when "ping"ing. That’s obviously awful, and a strong point against (3) (and that could be what is meant by "means changing the dependency tree of presence changing", I don’t know for sure what you meant by that.) > The server, equally is trivial with (2), while more work with (3). Especially for servers the work should be trivial for (3), possibly even less. Check for <rejoin-if-needed/>, if it’s there redirect to join code instead of sending an error. From a quick glance at the prosody (trunk) code, I feel this is a very trivial change. > 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. > >> 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. 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] _______________________________________________
