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).
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?
The way xmpp4moz works
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.
(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.)