On Tue, Jan 10, 2017 at 3:43 PM, Dave Cridland <[email protected]> wrote:
> On 10 January 2017 at 14:37, Kevin Smith <[email protected]> wrote: > > > > > > On 10/01/2017 14:27, Dave Cridland wrote: > >> > >> On 10 January 2017 at 13:30, Kevin Smith <[email protected]> wrote: > >>> > >>> On 10/01/2017 12:05, Steve Kille wrote: > >>>> > >>>> I have just issued a PR for MIX version 0.6.4. > >>>> > >>>> There is clear desire to have the option for MUC and MIX to use the > >>>> same > >>>> domain. The difficulty in achieving this was incompatible disco > >>>> results. > >>>> This version has made a change to > >>>> add node='mix' to channel disco that will enable the queries to be > >>>> disambiguated. > >>> > >>> I haven't been able to think of a case other than disco#items on the > room > >>> JID where MUC and MIX are likely to collide. This change doesn't make > it > >>> *easy* to implement both on the same domain, but I think it makes it > >>> viable > >>> - please shout if anyone can think of other cases. > >>> > >> I agree. Further, I only know of a single client that would ever hit > >> disco#items on a room, and that's Psi in its generic disco "browser". > >> > > Are you suggesting that this approach isn't necessary, and it'd be > > sufficient to 'break' disco#items handling for MUC-only clients? > > > > I'd not thought of this approach, but I was considering advocating > "just break". I think this means we don't have to. What about using Entity Capabilities to establish whether the client should receive MIX or MUC stanzas and syntax? I know that it's mandatory for every client to announce its caps but in such case the server could failover to default mode. I don't know unfortunately if all major clients include their version in initial presence...
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
