Having made the latest round of MIX edits, I felt it was time to share some thoughts on MIX.
It has been a number of years since work was started on MIX, and implementations are thin on the ground. It seems sensible consider when and if this will change. There are a number of reasons why MIX take-up is likely to be slow: 1. It is a big spec to implement for either client or server, even for a server with a good MAM and PubSub base. 2. The is a chicken/egg situation with clients and servers. A server implementor will wait until MIX clients are available and vice versa. 3. This does not appear to be an exciting new service (but see later). A simple view of MIX is that it is just a different way of providing an existing service, so there is not simple customer benefit or drive for MIX. 4. MUC broadly works. There are lots of little things broken, but there is no major issue to force replacing it. 5. MIX needs a migration. This will inherently slow things down and inhibit starting stuff. 6. Some in the community are working to address issues by updates to MUC. >From my perspective, this is "string and duct tape" and is not addressing deeper problems. Such activity will delay MIX. 7. Related to the above, some feel that MIX is just too much, and this definitely creates a feeling of "will MIX ever happen?". Predicting the future is hard, but..... Isode is committed to both server (M-Link COTS product) and client (Swift free & open source) implementations of MIX. We have strategic reasons to do this, particularly because of requirements on constrained networks. We have lots of other things we also need to do, but MIX is going to happen in our product set. It may well be that others will produce general purpose MIX implementations first (e.g., Surevine), but let's suppose this does not happen. It seems conceivable that MIX will end up as a specification that is useful for specific purposes, but not widely implemented (e.g., like XEP-0365). However, I do not think this will happen, as MIX has many benefits. I think that initial implementations will encourage others, almost certainly gradually at first. Once there are a few implementations, more will follow. Then MIX will be seen as something that modern XMPP implementations need to have and other implementations will play catch up. Let me justify this in terms of MIX benefits that I see: - Some of the broken bits of MUC that we all live with will become much clearer as MIX starts to be used. There will be a "how did I ever live with that" experience - Multi-client will become more important, and MIX will avoid a slew of MUC problems - "proper" history support will add value - Message only option will be important for constrained bandwidth and will facilitate observers (avoiding "presence clutter" from observers - As we work to build richer multi-user communication, with shared files, shared pictures, comments and likes, MIX is going to be the building block we need (that MUC is not) I do not think that this is going to happen quickly, but my (biased) bet is that MIX is going to happen Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
