On Tue, Jun 12, 2018, at 11:08, Georg Lukas wrote: > 1) improve the documentation and discoverability of the currently > defined / deployed behavior by doing small changes to 0045 > > 2) improve MUC by introducing new behavior into 0045 > > 3) create a new groupchat protocol that doesn't repeat any of MUC's > errors (i.e. something like MIX) > > The PR in question qualifies as 1 and *maybe* a bit of 2, and with an > according compatibility note I really don't see how it is *harming* MUC.
I meant "harming the MUC ecosystem, implementations, and muc server/client authors", not harming the spec itself which is made clearer by this addition. The problem as I see it is that, no matter how simple this change is, it adds complexity for new and existing implementations. For new implementations I now have to know the history of this change and know that I can't rely on it as we discussed before. Even if the language is improved to mention that the lack of an advertised feature can't be relied upon, it doesn't really change anything. I still can't rely on it and have to figure out what to do in the case of servers that don't advertise this feature. Do I just not support it on those even if they do support this flow? Do I implement whatever workaround I would have done before in which case why even bother with the feature? Assuming I already supported the voice request flow this just adds a shortcut I can take sometimes (which requires more logic in my client). If I didn't support it but want to, it doesn't make it any easier to support because I likely have to implement such a workaround anyways. Also, let's take a step back, why are we doing this anyways? Is this a feature that's widely used? Is it something that is actually needed to fulfill some requirement for MUC, or are we just making changes for the sake of fixing mistakes even though they're not actually a problem? Finally, let's think about how this affects the future. MIX doesn't have the voice request flow (I think? I should go back and look, but I'm pretty sure we decided against that), so do we want to encourage its use now, only to take the feature away again in the future? This makes the MIX transition harder because people like to complain when you take features away even if they never used them before. > On the other hand, I see benefits in improving the protocol, as it is > not going to go away soon. I'm also not sure what the alternatives are, > regarding 0045. Accept it with all of its shortcomings and move it to > Final to reflect that? Deprecate it without an alternative? Only > implement new features which can be unambiguously identified by a > biconditional feature flag in disco#info? I think I'd be happy with any of these options with the last one being on a case-by-case basis and with a preference for moving it to final. However, having an "alternative" implies that something needs to be done to MUC, and I'm not sure that anything necessarily needs to be done to it right this moment unless there are more seriouos problems that can be addressed without breaking things. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
