I've worked a lot with XMPP in a professional capacity and I have no idea what his complaint on that front it. It's trivially extensible; if you control both ends of the connection, grab a namespace and go to town. If you don't, you have to coordinate on the protocol, but XMPP won't get in your way. You can't do that with any other IM protocol that I know. (Which isn't all of them, but I do know a lot about a lot of them.)
There are other criticisms that make more sense, mostly to do with the annoyance of dealing with XML (especially for people that don't actually understand it; there's a bit more than meets the eye and XMPP actually uses thing like namespaces) and some valid complaints about verbosity (which mostly only matters in a mobile context), but there's a lot of other "standard" criticism that come more from ignorance than understanding, the biggest one being "complexity"; XMPP is modular, and if you just want to pop open a connection and send a message that's hardly a day's worth of coding starting from nothing more than a socket and an XML parser. If you don't want to be in a conference room, you don't have to worry about the conferencing standard, and so on.
There pretty much isn't another IM protocol that's even in the running for this sort of use, because XMPP is the only one that actually is extensible. The only alternative is specifying a protocol from scratch, and of course that hypothetical protocol is perfect and awesome... what with it not existing. Of course XMPP can't compete with the perfect protocols that exist only in people's imaginations (and note the plural... no two of them are the same). But XMPP actually exists, now.
>> " It's trivially extensible; if you control both ends of the connection, grab a namespace and go to town."
So what's the point of using xmpp at all? Why not just use a specific protocol geared to your use case? Using your own simple protocol is also trivially extensible. And human readable. Writing a parser for a json like syntax is also trivial - contrast this with an xml parser which is not trivial.
Why not use a better protocol to send email? Why are we still using HTTP to send web traffic, even though we've really gotten beyond what it is good at? Why am I FTP-ing a file even as we speak?
You're basically asking why utopia doesn't exist. You won't like the answers, so I'm not going to bother with them. All I can say is: Try it. See how far you get. I'm not kidding. This isn't just a rhetorical device. Go out and try to define your own protocol. See how many people rush over to join in. Maybe you'll pull off an Atom, but the odds are long.
(In fact, I do use my own protocol when I control both endpoints, even in a use case that looks a lot like XMPP, and in fact it is JSON based. The project I am working on right now has that as its backbone. But I know the limits of that approach. Bear that in mind as you try to understand where I'm coming from.)
Those protocols took off (HTTP/Email/etc). The network effect came into play.
XMPP never really took off (Big surprise). Using it for new, unconnected systems, is idiocy IMHO. There are probably more XMPP extension specifications than there are people using XMPP.
I agree, launching new protocols is hard. You need leverage and a network effect to get it going. I do get where you're coming from. I just think that anyone who has the choice on what protocol to use for something, and picks XMPP, is mad.
Even if it has to interface to legacy systems they could use a bridge.
This is a protocol which has quite a few rfc's associated with it (3920, 3921, 3922, 3923, 4622, 4854, 4979, 5437), as well as being proposed as an official internet protocol standard on the rfc-editor site. It isn't going away any time soon, despite your wishes otherwise.
RFCs and other documents do not mean it's needed or wanted - "Make something people want".
I'm sure it will limp on for years, after all, it's limped on for 10 years so far without real widespread adoption.
whatever, I presented the evidence that it is on a standards track, the IETF seems to like it, and it is a better protocol than any of the alternatives. I'm sure it is possible that one can come along one day to supplant it, but for the meantime it is the best we have and it would be nice if people would adopt a standard rather than whine about it not being done in their way.
in fact some amazing things might be possible if the service providers adopted it rather than maintain their proprietary walled gardens. I would love to be able to use my google talk account to initiate a jingle session with users on AIM/MSN/Yahoo/Facebok/etc.
Extensibility is really trivial. Human readable is trivial. Protocols based on XML solve neither of these well at all IMHO.
If XMPP ever did take off, we'd see a large increase in bandwidth usage everywhere. No doubt though they'd then just wrap it all up in another layer of complex compression to compensate for a ridiculous protocol.
This article is a "social media consultants" wet dream:
"Lay a foundation for a much more general computing and distribution infrastructure for context-aware, social-spreadable and trusted application scenarios that potentially enable users to regain control over their own graph of information and control access to it using social connections."
Hi there,
being the author of this article, let me just point out that I am _not_ an "social media consultant" but part of the scientific research carried out at www.linkedprocess.org. This article is merely trying to summarize and relate different computing approaches like Chat, GWave and others. Much of what is pointed out in this article is already either in the XEP (which is, others are actually extending the protocol and requesting these extensions to be standardized) or projects are exploring these scenarios (see the links in the comments and the article itself).
So, I don't think this is reality distortion, Google Wave and others placing their "next generation conversation" bets into this basket is IMHO a very fundamental endorsement.
XMPP is not the tightest of protocols, but it adds a lot of value in the outlined scenarios since you get internet-scale discovery, status handling, routing infrastructure and handling of extensions and custom payloads for free.
The XML overhead is IMHO only evident if you are either very low on bandwith (like mobile networks before flat rate and 3G) or parsing the XML yourself (not using the excellent client libs out there), so I think that is acceptable. I agree with some of the other comments that there never will be an ideal protocol, but this actually works, has exisitng deployments, clients and libs, and there are open servers and specifications to roll your own if you like.
It took a minute to wrap my head around it, but this thing has really got me thinking:
http://www.linkedprocess.org/
Summary: XMPP extension protocol to create remote VMs and inject code into them, language agnostic, asynchronous (you can leave the job running).
Until now, when I heard "distributed computing", I thought of number crunching, protein folding, etc. which doesn't excite me.
But think of it this way: with a ubiquitous system like this, you are effectively decoupling applications from resources. Instead of inventing formats to serialize data, or protocols to transfer it around, or RPC schemes to provide remote services, you just make everything available
locally in a sandboxed VM. Consumers inject code to assemble and transfer just the data they need, when they need it, with the power to deal with whatever constraints the network places on their particular use case.
Creating local APIs, in practice, is vastly easier than creating network protocols, especially when it comes to cooperation and standards. So... move the cooperation boundary to the easy part of the pipeline.
15 comments
[ 3.2 ms ] story [ 41.1 ms ] threadMost buzz words starting with 'X' from the 90s early 00s should be firmly laid to rest as terrible ideas built on more terrible ideas.
There are other criticisms that make more sense, mostly to do with the annoyance of dealing with XML (especially for people that don't actually understand it; there's a bit more than meets the eye and XMPP actually uses thing like namespaces) and some valid complaints about verbosity (which mostly only matters in a mobile context), but there's a lot of other "standard" criticism that come more from ignorance than understanding, the biggest one being "complexity"; XMPP is modular, and if you just want to pop open a connection and send a message that's hardly a day's worth of coding starting from nothing more than a socket and an XML parser. If you don't want to be in a conference room, you don't have to worry about the conferencing standard, and so on.
There pretty much isn't another IM protocol that's even in the running for this sort of use, because XMPP is the only one that actually is extensible. The only alternative is specifying a protocol from scratch, and of course that hypothetical protocol is perfect and awesome... what with it not existing. Of course XMPP can't compete with the perfect protocols that exist only in people's imaginations (and note the plural... no two of them are the same). But XMPP actually exists, now.
So what's the point of using xmpp at all? Why not just use a specific protocol geared to your use case? Using your own simple protocol is also trivially extensible. And human readable. Writing a parser for a json like syntax is also trivial - contrast this with an xml parser which is not trivial.
Why not use a better protocol to send email? Why are we still using HTTP to send web traffic, even though we've really gotten beyond what it is good at? Why am I FTP-ing a file even as we speak?
You're basically asking why utopia doesn't exist. You won't like the answers, so I'm not going to bother with them. All I can say is: Try it. See how far you get. I'm not kidding. This isn't just a rhetorical device. Go out and try to define your own protocol. See how many people rush over to join in. Maybe you'll pull off an Atom, but the odds are long.
(In fact, I do use my own protocol when I control both endpoints, even in a use case that looks a lot like XMPP, and in fact it is JSON based. The project I am working on right now has that as its backbone. But I know the limits of that approach. Bear that in mind as you try to understand where I'm coming from.)
XMPP never really took off (Big surprise). Using it for new, unconnected systems, is idiocy IMHO. There are probably more XMPP extension specifications than there are people using XMPP.
I agree, launching new protocols is hard. You need leverage and a network effect to get it going. I do get where you're coming from. I just think that anyone who has the choice on what protocol to use for something, and picks XMPP, is mad.
Even if it has to interface to legacy systems they could use a bridge.
Google could easily switch protocols and provide a legacy xmpp bridge tomorrow if they chose to.
in fact some amazing things might be possible if the service providers adopted it rather than maintain their proprietary walled gardens. I would love to be able to use my google talk account to initiate a jingle session with users on AIM/MSN/Yahoo/Facebok/etc.
My previous comment on the matter: http://news.ycombinator.com/item?id=426581
Extensibility is really trivial. Human readable is trivial. Protocols based on XML solve neither of these well at all IMHO.
If XMPP ever did take off, we'd see a large increase in bandwidth usage everywhere. No doubt though they'd then just wrap it all up in another layer of complex compression to compensate for a ridiculous protocol.
"Lay a foundation for a much more general computing and distribution infrastructure for context-aware, social-spreadable and trusted application scenarios that potentially enable users to regain control over their own graph of information and control access to it using social connections."
Now, back to reality...
So, I don't think this is reality distortion, Google Wave and others placing their "next generation conversation" bets into this basket is IMHO a very fundamental endorsement.
XMPP is not the tightest of protocols, but it adds a lot of value in the outlined scenarios since you get internet-scale discovery, status handling, routing infrastructure and handling of extensions and custom payloads for free.
The XML overhead is IMHO only evident if you are either very low on bandwith (like mobile networks before flat rate and 3G) or parsing the XML yourself (not using the excellent client libs out there), so I think that is acceptable. I agree with some of the other comments that there never will be an ideal protocol, but this actually works, has exisitng deployments, clients and libs, and there are open servers and specifications to roll your own if you like.
See the piece as a summary, not a roadmap.
Cheers
/peter
Summary: XMPP extension protocol to create remote VMs and inject code into them, language agnostic, asynchronous (you can leave the job running).
Until now, when I heard "distributed computing", I thought of number crunching, protein folding, etc. which doesn't excite me.
But think of it this way: with a ubiquitous system like this, you are effectively decoupling applications from resources. Instead of inventing formats to serialize data, or protocols to transfer it around, or RPC schemes to provide remote services, you just make everything available locally in a sandboxed VM. Consumers inject code to assemble and transfer just the data they need, when they need it, with the power to deal with whatever constraints the network places on their particular use case.
Creating local APIs, in practice, is vastly easier than creating network protocols, especially when it comes to cooperation and standards. So... move the cooperation boundary to the easy part of the pipeline.