Which interoperability?
2007-09-12 14:49:35 by Fabio FornoWhen designing and some new IM based services two concepts of interoperability are available:
- try to offer your service to most IM systems
- chose an open protocol, that's to say XMPP, and stick to it
Apparently the first solution seems more portable. Try to imagine a small startup like ours seeking for venture: the first question in the interview could be "how large is your market?". You sum the figures of MSN, AIM, Yahoo GTalk and others and you get the impressive number of few hundred millions. Impressive uh? You say "I'm using XMPP, GTalk and few others use it" and you have almost failed the entry question, since your figures lose at least a zero.
The problem is that this kind of interoperability is the dark side of the force: don't be too greedy with the figures, but choose a solution that can grow, because you may end up with a large unsatisfied user base not using your service.
Let's explain it with an example. In the last days I've tested the IM integration of Twitter and Jaiku and today I've tried Plugoo , a flash based widget embedding a chat window into a web page and allowing visitors to chat with the page owner. Twitter and Plugoo are interoperable accordingly to the first concept: they allow you chosing any IM system. Jaiku, instead is committed to XMPP only. All these systems have few usability issues, since IM integration is new and there are no well known patterns for solving problems. However the more promising is Jaiku: many of its issues are being addressed and the developers have plenty of options for improving the service (multi user chat for channels, a savvier use of resources, x-html, ad hoc commands, client capabilities, just to list some features of XMPP that may be handy). Instead I don't see many chances for improving Twitter IM integration and Plugoo: apparently open, they are stuck to the small (almost null) subset of common features of the adopted IM services. Any improvement is stopped, but simply (in term of of expressiveness) and cumbersome (for users' interaction) text based commands, that's to say they are forced to used '90s like solutions when ICQ and IRC were already there.
So, when asked "how many users?", just say "one day as many as Internet users, XMPP will be as ubiquitous as now SMTP and the Web are. Why? Because it's the only way to make things work, the other will simply fail" ;)
This is an excellent point, Fabio. I see the same going on with some libraries: they insist on providing an abstracted, unified vision of many protocols; but for that you need a common denominator... and you end up with a minuscule, non-extensible, chat-oriented subset of XMPP. Pity, pity, pity.
> You say "I'm using XMPP, GTalk and few others use it" > and you have almost failed the entry question, > since your figures lose at least a zero. Wrong: They only lose fame. The real "thing" is: XMPP gets you MSN/WLM, AIM, ICQ, Yahoo! Messenger, but let's not forget the non-more open, but less famous Gadu-Gadu, QQ, Nate On, MySpaceIM, for which transports are do-able or already available. Besides, you can say that the biggest IT industry leaders have products and services based on XMPP: IBM, Sun, Google, Adobe, Oracle, JBoss, Red Hat, HP, Apple... and so many open source projects and communities.
Gateways have the same problems of multiprocol clients: you can't base your service on all the advanced features of XMPP, so you can't count on them (unless you tell a small lie ;))
While gateways provide a nice solution for the short term, it is really a stop-gap. To start with, they don't really scale. Legally, they are very questionable at best and certainly for entities that want to provide a service like an IM bot. A true solution would be interoperability at the server-to-server level. And although the foreign entities have less capabilities, they could still more or less participate using the plain-text interface provided now.
Agree. What I'm say basically is: it's time to start saying that you support XMPP olny, not being afraid of designing services using the advanced XMPP features (e.g. now I'm answering using a dataform in psi and this can't be done with any other protocol)
@ralphm: "To start with, they don't really scale." This is a technical solution that can be fixed. "While gateways provide a nice solution for the short term, it is really a stop-gap. " If you call transports short term minded, multi-protocol clients are ultra-ultra-ultra short term minded ;-) Transports can "steal" community from multi-protocol client projects to Jabber clients...in this way transports are an investment in the future of Jabber B-) "Legally, they are very questionable at best and certainly for entities that want to provide a service like an IM bot." There is nothing legally questionable about running transports. You just have to avoid to run your service in countries with a wrong law. Anyway, in the EU this would be perfectly legally. Of course, I agree transports are only a temporary solution; they can be dropped when the closed systems opened their service :-) Oh yes, at the same day as this blog post was written I started writing a blog post "Why Transports Matter". Maybe I'll post it somewhere next week. You will hopefully better understand my replies here after you read that. Stay tuned ;-)