Dave,
We’ve been looking at operating MIX without MIX-PAM. It seems clear that trying to do this is rather against a basic part of the MIX model (sending messages to users, not clients) and is fraught with issues, particularly multi-client. I feel quite strongly that we should NOT attempt to address this in MIX-CORE. It will add messiness to an already complex spec. I think that if someone really wants to pursue this, that it should be written as another spec in the MIX family. In this way, it will be clear what needs to be done differently when operating without MIX-PAM Steve * I think MIX can be made to work (albeit less efficiently) without MIX-PAM. This last point needs a detailed explanation, of course, both in terms of motivation and design. Firstly, the motivation here is that currently, MIX needs a substantial fork-lift upgrade to get deployed. Every entity on the path of MIX needs to implement, and deploy, some MIX in order to work. The benefit of this is obvious, of course - it means an efficient, and very solid, design, and it's certainly where we need to get to. But getting There form Here is going to be difficult, since who wants to implement MIX in their client if the servers need to support it, and so on. By having MIX channel servers able to directly interoperate with MIX clients even if the home server doesn't support MIX, I think we're able to accelerate deployment. [Steve Kille] The motivation is clearly a good one. It seems clear that this should be supported if not overly disruptive. The changes needed are: a) A MIX client needs to determine if its home server supports MIX-PAM. If it does not, a "Direct Join" is used - which is simply exactly the same join but sent directly to the MIX with full jids. [Steve Kille] I think that makes sense. It can be optional for a MIX server to support this, so there is no overhead for a MIX implementation that does not want to support this. Agreed. b) A MIX channel receiving a direct join implies the client's home server does not support MIX-PAM. It then uses bare Jids in its Participants items still, but sends messages addressed to the full jid of such clients. [Steve Kille] Going offline needs some consideration. Messages addresses to the full JID would be discarded. I think that this means that the direct client would need to leave before it goes offline. Also, if the MIX channel gets a bounce from the bare JID, it needs to assume that the client has gone away, and auto-leave the client. There is also danger of getting back into a slew of multi-client issues in MUC, which MIX fixes. A simple approach would be to only allow one Direct Join for a given bare JID. I think it's almost certain that without MIX-PAM, there will be a slew of multi-client issues left unfixed. It might be worth looking at the various "MUC Lite" proposals to see if there are any cheap ways to partially address these that have already been thought of. c) When reconnecting, a MIX client which has performed a direct join in a previous session may have to leave and rejoin - assuming it cannot maintain the same resource. [Steve Kille] I think the client needs to leave if going offline. This operation without MIX-PAM seems messy, once you get into the details (and there will likely be more). It's an absolutely unapologetic hack, yes. The question is can we get something that - while certainly flawed - might be sufficiently better than MUC that we can use it as a stepping-stone? I’d like to see other opinions on this, before I consider any editing So would I, very much. The changes noted above have been made and pushed as a XEP-0369 update. Thanks! Dave. [Steve Kille] Regards Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] <mailto:[email protected]> _______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
