[Standards] XMPP team activity

Peter Saint-Andre - &yet peter at andyet.net
Tue Sep 29 15:47:32 UTC 2015


On 9/29/15 8:30 AM, Ralph Meijer wrote:
> On 2015-09-29 12:55, Evgeny Khramtsov wrote:
>> Tue, 29 Sep 2015 12:25:28 +0200
>> Stefan Strigler <stefan.strigler at gmail.com> wrote:
>>
>>> Strange, I'm being paid since years for doing exactly this.
>>
>> I'm doing just the same. With a few proprietary extensions this can be
>> done just fine. But I think that is not the right direction for XMPP
>> developers in general.
>>
>>> You're free to contribute!
>>
>> But what if I disagree on some positions with XSF? Like jingling or
>> pubsubbing everything. Obviously I cannot contribute to the solution I
>> don't see useful. I wouldn't complain if they worked fine, but
>> they don't.
>
> Hi,
>
> I've been reading this thread and want to make a few things clear about
> XMPP, the XSF, and the community, and how they relate.
>
> First off, I'd like to make it clear that the XSF is (just another)
> standards body that tries to find common ground in real-time messaging
> applications. It does that by providing a process for enhancement
> proposals to be examined on technical merit, basically to define a
> collection of generic building blocks to build real-time applications.
> This process eventually results in published documents in the form of
> XMPP Enhancement Proposals (XEPs) and is guided by the XMPP Council that
> is elected from and by the XSF membership.
>
> Additionally, the XSF tries foster the XMPP community by providing
> discussion venues (mailing lists, group chat rooms and summits), being a
> representative towards other (standards) bodies, and even being a mentor
> organization for Google Summer of Code to improve implementations of
> real-time applications based on XMPP.
>
> However, we do not control the community. This is important. The
> community is bigger than the XSF and due to nature of how XMPP is
> distributed in nature, both in architecture and in how you can define
> extension protocols, it cannot be the end-all and be-all of everything
> XMPP. Also note that the core XMPP protocols are defined in another
> standards body: the IETF.
>
> The XSF itself also does not currently provide, endorse, or actively
> contribute to XMPP implementations. In fact we have so far actively
> tried to not favor particular server, client and library implementations
> in our communications.
>
> To get back to your original remarks. Yes, it is ok for applications to
> have proprietary extensions. Sure, we'd love to define a generic way for
> extensions that are common enough to be of general use. Often, though,
> running code beats standards documents. Building first and then coming
> to the XSF to define it properly based on experience is a great
> approach. Even if it is using a different approach than other
> enhancement proposals. If anything, it improves discussion around a
> certain problem domain. Disagreement is a great conversation starter.
>
> Additionally, you say that you don't like "jingling or pubsubbing
> everything". As it turns out, there are patterns in the different
> building blocks we've thought up over the last 17 years. If we were to
> redesign the whole thing, stuff might look a lot different. Jingle is
> the culmination of work on several different approaches towards
> signaling for setting up audio/video connections and file transfer. In
> fact, Jingle's development was a great influence to how WebRTC has been
> designed and why it is a natural fit for signaling WebRTC applications.
> I'd also say that because of WebRTC, it is easier to take those building
> blocks and reuse them for non-web implementations, using Jingle.
>
> The observer pattern (also known as publish-subscribe) is hidden within
> almost all of our building blocks. In fact, I know of at least one
> server implementation that is wholly publish-subscribe based, but
> provides access using the standard (non XEP-0060-based) protocols. This
> is why you will hear a lot of talk about publish-subscribe for a next
> generation multi-user chat protocol. It is just a good fit and solves a
> bunch of problems that are currently really hacks in XEP-0045.
>
> But I think most of the "it doesn't work" is not because of protocol,
> but actual implementations. Like you, I'd love to see a system like
> Whatsapp, Slack, GitHub, etc. using standard XMPP protocols with a great
> UI for all major platforms (web, Android, iOS, Windows Phone, Linux
> desktop, OS X, and Windows desktop). However, again, this is not the
> domain of the XSF. Some one, some group or some company, would need to
> invest time and money to make this a reality. I don't believe the
> protocols themselves are the issue here. Implementations are.
>
> Also note that XMPP is way more than "just chat". There is a big effort
> around non-persons communicating using XMPP, including the so-called
> Internet of Things (IoT).
>
> In the end, this is simply a doacracy: those who do the work get stuff
> done. Work includes writing code, documentation, UI design, research,
> and cooperation with other standards bodies. As you mentioned,
> implementations are in different states regarding the implementation of
> (sometimes still experimental) extensions. To align them, people will
> need to dig in and bring together implementors. The XSF is surely a
> great place to facilitate such discussions, but is not in a position to
> enforce convergence around certain applications.

A big +1. Post this on the XSF website somewhere!

Peter

-- 
Peter Saint-Andre
https://andyet.com/



More information about the Standards mailing list