English is weird in lots of ways, so are linguistics in general. I will only point out that when you described "lite" you used "light" in the very same context you used to try and differentiate them.
-bjc > On Dec 14, 2015, at 17:18, adansdpc <[email protected]> wrote: > > Hi everyone, > > Excuse me for the impertinence, but I needed to ask: why "muclight" and not > "muclite"? > > One byte is one byte! In addition, "lite" is better understood for lightness > (small weight) than "light", that is likely to be confused with the > brightness emitted by the sun and glowing objects, IMHO. > > Best, > Adán > > > -------- Mensaje original -------- > De: Dave Cridland <[email protected]> > Fecha:14/12/2015 07:09 PM (GMT+01:00) > Para: XMPP Standards <[email protected]> > Cc: > Asunto: Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light > > > >> On 14 December 2015 at 17:08, Stefan Strigler <[email protected]> >> wrote: >> >> 2015-12-14 16:16 GMT+00:00 Dave Cridland <[email protected]>: >>> >>> >>> 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. >> >> The service identifies itself as >> <feature var='urn:xmpp:muclight:0'/> >> over disco-info. Not sure where any confusion could come up here. > > The two are a subtly different model. You cannot have a full XEP-0045 room > also exposed by this protocol, and exposing this protocol by '45 would force > some limitations on how '45 operated (such as refusing certain affiliation > changes, etc). > > Yes, of course you can implement both on different servers. > >> >>> Mobile-friendly is fine, mobile-only is not. >> >> It is not mobile only, there is absolutely nothing that would prevent a >> desktop client from implementing that protocol. > > Sure, but it is entirely and completely focussed on the current state of > mobile to the exclusion of all else. > >>> >>> 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. >> >> The intention of this proposal is to resemble functionality that's present >> in competing products like Whatsapp et al at a level that's as simple as >> possible to implement, esp when focusing on clients. Mobile clients, sure. >> It is by no means undermining the extensibility of XMPP, all it does is >> exposing a reduced set of functionality as found in MUC over its own new(!) >> namespace while reusing parts of things found in MUC for ease of >> implementation. >> >> It is not meant as a replacement for MUC, nor is it meant to block or stop >> any other efforts to come to a more generalized solution to the same >> problem. But it is an ad-hoc approach that solves a problem right now. At >> the protocol level as implementation wise (since we have one for >> MongooseIM). It documents what we actually do. And I don't see where it does >> any harm (because it sounds so at times). > > It causes harm by balkanization - the part of my message you stripped out > before replying. > > That's not to say that you shouldn't implement something along these lines, > of course - you can do whatever you want - but I don't think it's suitable > for general standardization. > > In particular, I'd want something that supports the same requirements as this > but also can support the existing ones and additional requirements currently > unmet by '45. > >> >> Cheers, >> >> Stefan >> >> _______________________________________________ >> 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] _______________________________________________
