> 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. 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). The server, equally is trivial with (2), while more work with (3). 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. >> makes it easier if one wants to write a MIX proxy (so allowing users >> to join MUCs as if they were MIXs, and have the server do all the work >> for them - which would be a nice thing, I think). > > I'm with you here - the self-ping would have to be implemented by the > proxy (if at all), but you have to implement it anyway to provide > reliable functionality, be it (2) or (3). I very obviously don’t have a concrete implementation of a proxy yet, but for the design I’m currently thinking about, (2) is less complex. > >> 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. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
