On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote: > On 4 Oct 2017, at 16:41, Jonas Wielicki <[email protected]> wrote: > > On Mittwoch, 4. Oktober 2017 16:08:43 CEST Kevin Smith wrote: > >> 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.
Sure. > >> 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. Okay. So what would a more complete solution look like? One idea I have is to use (2), but also specify a new feature and <presence/> payload for MUC (let’s call it <no-join/>). A MUC service would handle it as follows: 1. If the sender is currently joined, the presence is handled as usual. 2. If the sender is currently not joined, *no* GC 1.0 join takes place. Instead, a <presence unavailable/> is sent back, which MAY carry the original status code and message from when the sender was last removed from the MUC and SHOULD include the 'kicked' status code. (In contrast to <rejoin-if-needed/>, this does not rejoin the sender automatically.) Then MUC client implementations just need to tell the directed presence thing that <no-join/> needs to be included in each presence cast to the MUC. MUC services only need to check for <no-join/> in the GC 1.0 handling and advertise the feature. MUC client implementations use the ping to detect whether they are joined. What do you people think? 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] _______________________________________________
