Why xmpp4moz needs to be a standard: What's wrong with XEPs?

This post is a long-awaited post for me, but I felt the motivation again after viewing and browsing Douglas Crockford's videos about JavaScript.

First, let me tell you that the IM war is mostly a war on user experience. The more fun the user can get with a given IM-solution (by which I mean both protocol, client, and service provider), the more possibly he's likely to use it. There's nothing with the network effect here: if we really wanted, we could already solve that with transports!

What is jabber? It's

• An open network with many service providers


• A core protocol (standardized in RFC 3920 and RFC 3921)


• A set of optional extension protocols, called XEPs

The fate of CORBA

Of course it's nothing a user deals about, it's the thing evangelionists care about, which is nearly good enough. Corba was such a protocol in the nineties, with a core protocol, and a lot of extensions. It was born for interoperability between vendors.

But: Corba isn't used today mostly. Corba died in the fact, that most of its parts are optional - this way there's practically no two "ORB"s, which could communicate with each other - sometimes even from the same vendor on two different platforms! This way the open ecosystem of CORBA components simply never were to be born: it was always vendor dependent, and gave its place to other vendor-dependent (Java RMI, .NET Remoting), or more formal (XML-RPC, SOAP WebServices) protocols in order to achieve a greater interoperability market, not to mention JSON and other grassroot standards.

It cannot be argued that a network supporting all the XEPs currently in draft, final or experimental would be superior to most of today's IM network. But there's no such network, and without changes it isn't likely to be born, even if XMPP is the only standing standard between formal IM protocols. As one on jdev expressed:

We already won, it's just the thing nobody noticed this except us.

What's the problem with this XEP thing anyway?

The jabber network - by which I mean the open network of providers supporting the XMPP protocol - is a heterogenous environment: not only there are different server implementations and policies, but there are different clients as well. There were 10 clients with a larger marketshare than 3 percent on jabber.ru last month! And that's only one of the service providers, with a popular and feature-rich server implementation. What could those users on that network do with each other? It was determined by:

• The core protocol support itself


• The support of extensions by the server implementation


• The support of extensions by the client implementations

What was the largest denominator? What was the bottleneck? I think you already guessed:

An XMPP network supports those XEPs which are supported by all (or vast majority) of the participating implementations - both servers and clients.

Which exaggerated means that

The open jabber network practically does not support (almost) any XEPs, because there's always a client or server between a large share of pairings which does not support the given XEP.

In need of the algorhythm

XEPs are basically data formats to be exchanged between two parties, but sometimes they even define a protocol of interchange. But what could a client do with plain data? Of course nothing. It needs an algorhytm to process the data and give an answer. Since the XEPs theirselves aren't formal definition in a computer science perspective (using SHOULD and MAY is formal for a human, but not for a computer). The former JSF process put the implementation in the hands of client authors, making it the responsibility of them to implement them. Of course, every client author picked up their own choice of implementing XEPs, and there's hardly an intersection between them.

So what we would need is either:

• An official repository of processing alghorythms with formal description, which means in some kind of computer language, to which an interpreter/compiler could be written for clients


• Make the processing instructions travelling with the data package, possible with weak linking (eg. a processing URL)

An official repository could be needed if the processing could do malicious or privacy-problematic things on behalf of user, either centrally, or by signing it with usual keys (eg. a client could accept a corporate SSL certificate to use their implementations in an EIM environment, and official XSF-signed extensions).

Representation

Of course, if we have the data, and have the alghorythm, one could argue, that a layer is still missing: the view layer. And one could argue that this should vary from client-to-client, but if we do inspect today's popular IM solutions, we should find out that all of the corporate rivals (MSN, AIM, YIM, ICQ, etc) use an HTML rendering system in that layer in official [windows] clients; while it could be argued that some XMPP clients does not, but it does not mean it's a right way: by using the broad market of HTML rendering engines (Gecko,Webkit, Windows' CHtmlEditCtrl...), a lot of diplay problems could (and should?!) be solved.

There's even a space for interactive applications, like board games, crayon-based whiteboards (which I really liked in Yahoo!'s IMVironments), all which could be done by using a proper HTML-based rendering engine and some common features which all clients could share.

While HTML is in itself probably a bad idea, XHTML isn't much difference, while it's still XML. Therefore, XSLTs and CSSs could still be used over it, giving a client's own look and feel. XSLT is also formal: it could give XSF a tool by which recommendations could be written into XEPs.

Hey! It would be even useable on webclients and an iPhone :)

A processing language for view layer?

It's also arguable that XSLT in its own would be enough to write collaborative applications, games, etc, but hey, we already have a good view-layer language: it's called JavaScript, and its core features are used in many interactive application frameworks, most notably Flash and XUL. And this is again a part where HTML rendering engines come in: they have a natural support of JavaScript.

But there's also support (or, to be correct, a variant) in Flash, in Java (have you heard of Rhino?), in KDE applications, and in C: basically everything. Webclients are in fact written either in JavaScript, or its variant, ActionScript (OK, there's Jeti as an exception, I know), so they could also have some support of collaborative JavaScript applications.

The way xmpp4moz works

xmpp4moz by hyperstruct thinks XMPP of a communication layer, on which collaborative applications could be built. It uses the XUL variant of JavaScript [unfortunately, but we'll deal it later], which means it makes the browser-application "presence-enabled" so applications written in javascript could talk with each other. Of course there are security restrictions: namely an application could only catch those messages which are for the conversation the application currently runs in (can be a MUC or a private conversation). While it's strange for the first minute, since there's no authority, and any webpage could use some collaborative features by using this framework, it's a viable decision.

After all, it's a good thought: collaborative applications resides on their own webpage, and they can be used by calling them from a presence-enabling framework; this would fit very well to the web ecosystem. This could be a browser, or a desktop client.

The only problem is that xmpp4moz uses firefox-only javascript methods, which are good if you want to expand firefox's possibilities, but is a very wrong approach when you want to design a new collaborative application standard, but it's not a thing which couldn't be solved: after all, both XIFF, JSJaC, libstrophe-JS and xmpp4moz should have their common denominators. But I left this to solve for You.

(All the above text is merely a personal opinion, sometimes perhaps made more pessimistic than in reality to catch attention and start arguments; it's not an official statement nor I think the XMPP world is simply wrong at all.)