[Standards] Proposed XMPP Extension: Multi-User Chat Light

Brian Cully bcully at gmail.com
Tue Dec 15 06:37:14 UTC 2015


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 <adansdpc at waalt.com> 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 <dave at cridland.net> 
> Fecha:14/12/2015 07:09 PM (GMT+01:00) 
> Para: XMPP Standards <standards at xmpp.org> 
> Cc: 
> Asunto: Re: [Standards] Proposed XMPP Extension: Multi-User Chat Light 
> 
> 
> 
>> On 14 December 2015 at 17:08, Stefan Strigler <stefan.strigler at gmail.com> wrote:
>> 
>> 2015-12-14 16:16 GMT+00:00 Dave Cridland <dave at cridland.net>:
>>> 
>>> 
>>> 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: Standards-unsubscribe at xmpp.org
>> _______________________________________________
> 
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151215/5854e74d/attachment.html>


More information about the Standards mailing list