On 14 December 2015 at 16:04, Piotr Nosek <[email protected]> wrote:
> Hi Dave, > > a) It retains some level of compatibility, please see Implementation > Notes. It is possible to use 0045 protocol for most of the functionality in > transition period. "Substantial chunk of work" is not very precise. In our > case the initial implementation that did not support 0045 compatibility > took about 2-3 weeks. Please note it included refining the protocol in the > meantime, so it was not pure implementation of existing, ready standard. > > No, you cannot have an arbitrary XEP-0045 service also presented over this protocol; it has to be a cut-down, especially written service. The result is that existing '45 features are lost entirely. An example is multiple owners, but there are plenty of others. > b) It is a compilation of requirements of mobile chat providers. I can't > see why being useful only for mobile clients is a reason to treat is as > useless. It is a common belief amongst many developers that XMPP is not > very attractive for mobile environments, why can't we make several > extensions that are specifically mobile-friendly? > Yes, there is no possibility of sending IQs but the thing is - what > IQ-based functionality we would need in groupchats? File transfer? It's a > common practice nowadays to upload files to external storage like Amazon S3 > and then just send a message with a link. (extra benefit: it can get > archived by MAM). > > Mobile-friendly is fine, mobile-only is not. Many of the facilities you're dropping from '45 are in use in various places - what I'd hate to see is a balkanization of XMPP between mobile users and non-mobile users. The point of XMPP is extensibility - by blocking off extensibility because you don't think the existing cases are important enough, you're also blocking off use-cases none of us have thought of. > Regards, > Piotr > > On Wed, Dec 9, 2015 at 10:48 AM, Dave Cridland <[email protected]> wrote: > >> This is quite a substantial protocol, but has, I think, two issues which >> mean it is problematic to accept in my opinion: >> >> a) It is not just presence-less MUC. It's an entirely new protocol which >> is incompatible with existing XEP-0045. Even the room affiliation model is >> different, allowing for example only one owner. This is problematic because >> it's not reusing much (if anything) of the existing infrastructure. As such >> it's going to be a substantial chunk of work for server developers to >> implement, and difficult to offer a transitional approach into XEP-0045 >> based services. >> >> b) It is only presence-less MUC. It's not offering anything beyond simple >> fan-out of chat messages, and as a result there is no incentive for >> non-mobile, or non-chat, clients to adopt it. As an example, there's no way >> to send any IQ traffic through the system, due to a combination of no >> visibility of either presence or full jids, meaning there's no possibility >> of, for example, file transfer. >> >> I appreciate there is a degree of not wanting to accept it because we're >> expecting a MUC2 protoXEP to arrive, however I'm trying not to let that >> influence my thinking here, since there's currently no XEP. >> >> On 8 December 2015 at 17:39, XMPP Extensions Editor <[email protected]> >> wrote: >> >>> The XMPP Extensions Editor has received a proposal for a new XEP. >>> >>> Title: Multi-User Chat Light >>> >>> Abstract: This specification provides a presence-less standard for >>> Multi-User Chats. Its feature set is a response to mobile XMPP applications >>> needs and specific environment. >>> >>> URL: http://xmpp.org/extensions/inbox/muc-light.html >>> >>> The XMPP Council will decide in the next two weeks whether to accept >>> this proposal as an official XEP. >>> >>> >> >> _______________________________________________ >> Standards mailing list >> Info: http://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> _______________________________________________ >> >> > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
