On Donnerstag, 5. Oktober 2017 12:20:12 CET Kevin Smith wrote: > > On 5 Oct 2017, at 11:39, Jonas Wielicki <[email protected]> wrote: > > > > On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote: > >>>> 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? > > That sounds simpler to implement than (3), certainly, so it seems preferable > to me (although if we can get away without presence annotation at all, even > better). > > Two other things for discussion: > > 1) Could implementations make gc1 support a configuration option, default > ‘off’. > 2) Could we remove the gc1 compatibility from xep45 and suggest > people drop it? Interestingly, gc1style joins have no namespace associated > with them, and no discovery, so it’s probably not a namespace bump (I think > we’re all going to agree that bumping MUC’s namespace would be > undesirable).
If I recall correctly, abandonment of GC1.0 has been rejected by previous council (I don’t know the details, sorry). So, do we agree that my alternative proposal (see above; Georgs (2) + <no- join/>) would be a good idea™? Can we get some server and client devs onboard to test this first, or shall I write up a patch for XEP-0045? (Maybe this is something for Summit?) 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] _______________________________________________
