5 ms·

FWIW, I think XMPP solves problems in a completely horrible way. It's ridiculously over engineered, verbose, needlessly complex, overly extensible to the point

by axod 16y ago

FWIW, I think XMPP solves problems in a completely horrible way. It's ridiculously over engineered, verbose, needlessly complex, overly extensible to the point of absurdity. It totally makes sense to create a concise, specific protocol to solve a specific problem when appropriate. Learn from the hundreds of mistakes that were made in the 90s and early 2000s when all this X* came out.

dminor 16y ago
Actually the core of XMPP is fairly small - an XMPP server need not implement every extension ever conceived of. Given that it's widely deployed, solves the presence and federation, and is implemented in a wide variety of languages, I think the GP is right. The only real nit that I see is with mobile devices - XMPP isn't great for low power low bandwidth situations.
- imaginator 16y ago
  Holding a socket open on a mobile costs nothing. Sending data through that open socket will quickly jump the phone into DCH state (http://xmpp.org/extensions/xep-0286.html#sect-id115219 http://xmpp.org/extensions/xep-0286.html#sect-id115219). Polling is worse. Google keep the chat client open but have an option to hold back all but the most important packets on the server side and then batch send them after a set period of time. This is something along the lines of http://xmpp.org/extensions/xep-0273.html http://xmpp.org/extensions/xep-0273.html The current nokia version of buddycloud (http://mobile.buddycloud.com http://mobile.buddycloud.com) will run continuously for for about 18 hours. The android version with batch sending of packets even longer. And if you worry about XMPP's verbosity, just add the DEFLATE option to your TLS socket. That drops the size down to about 10% of the original.
rtreffer 16y ago
And diaspora solves communicating in a horrible was. No chat (but expect it to be XMPP based), no real time, horrible tunneling of wired stuff over http. Besides that: Most users already have XMPP accounts with friendlists. I'm eager to see how diaspora will solve that problem.
hamidp 16y ago
The base XMPP protocol plus the IM extension is pretty straightforward to implement. It's XML, so you don't have to write your own parsers, which get extremely complex and buggy, especially if you're doing beyond the trivial. The extensibility is absurd only if you have a terribly-written library. With a semi-thought out and designed library you can write a simple code generator that will parse out the XSDs and generate your classes, structs, enums, and whatever else, greatly reducing the cost of implementation. The problem with a "concise, specific protocol" is that it's only concise and specific if you never, ever plan to change anything. Let's say that you designed the best protocol ever. Then in the next release you realize that you really ought to add this one small thing to the protocol: * How do you distinguish between the versions of the protocol? * How do you bridge between clients that understand the new thing and those that don't? * How do you tell the existing clients that they should upgrade? * How long do you maintain the old version without the super-awesome new thing? * Once you decide to deprecate the old version of the protocol what do you do with the older clients? And oh, by the way, in the release following you decided that you need to slightly tweak the super-awesome thing you added to the protocol. Good luck.
moeffju 16y ago
It solves roster/presence and federation. The core of XMPP is pretty small; the extensions are numerous, but you don't have to implement them (if you're just using XMPP for the federation or as a messaging layer) for the most part. You also get the advantage of tried and true libraries for a lot of languages, which saves you from reinventing the wheel again. There are stable servers and usable clients to help you in development, and the documentation of the protocol is pretty good. Also using things like HTTP-Bind interfaces, you can basically use XMPP without keeping a connection open. All this flexibility has its use.

by axod 16y ago

dminor 16y ago

Actually the core of XMPP is fairly small - an XMPP server need not implement every extension ever conceived of. Given that it's widely deployed, solves the presence and federation, and is implemented in a wide variety of languages, I think the GP is right. The only real nit that I see is with mobile devices - XMPP isn't great for low power low bandwidth situations.

imaginator 16y ago
Holding a socket open on a mobile costs nothing. Sending data through that open socket will quickly jump the phone into DCH state (http://xmpp.org/extensions/xep-0286.html#sect-id115219 http://xmpp.org/extensions/xep-0286.html#sect-id115219). Polling is worse. Google keep the chat client open but have an option to hold back all but the most important packets on the server side and then batch send them after a set period of time. This is something along the lines of http://xmpp.org/extensions/xep-0273.html http://xmpp.org/extensions/xep-0273.html The current nokia version of buddycloud (http://mobile.buddycloud.com http://mobile.buddycloud.com) will run continuously for for about 18 hours. The android version with batch sending of packets even longer. And if you worry about XMPP's verbosity, just add the DEFLATE option to your TLS socket. That drops the size down to about 10% of the original.

rtreffer 16y ago

And diaspora solves communicating in a horrible was. No chat (but expect it to be XMPP based), no real time, horrible tunneling of wired stuff over http. Besides that: Most users already have XMPP accounts with friendlists. I'm eager to see how diaspora will solve that problem.

hamidp 16y ago

The base XMPP protocol plus the IM extension is pretty straightforward to implement. It's XML, so you don't have to write your own parsers, which get extremely complex and buggy, especially if you're doing beyond the trivial. The extensibility is absurd only if you have a terribly-written library. With a semi-thought out and designed library you can write a simple code generator that will parse out the XSDs and generate your classes, structs, enums, and whatever else, greatly reducing the cost of implementation. The problem with a "concise, specific protocol" is that it's only concise and specific if you never, ever plan to change anything. Let's say that you designed the best protocol ever. Then in the next release you realize that you really ought to add this one small thing to the protocol: * How do you distinguish between the versions of the protocol? * How do you bridge between clients that understand the new thing and those that don't? * How do you tell the existing clients that they should upgrade? * How long do you maintain the old version without the super-awesome new thing? * Once you decide to deprecate the old version of the protocol what do you do with the older clients? And oh, by the way, in the release following you decided that you need to slightly tweak the super-awesome thing you added to the protocol. Good luck.

moeffju 16y ago

It solves roster/presence and federation. The core of XMPP is pretty small; the extensions are numerous, but you don't have to implement them (if you're just using XMPP for the federation or as a messaging layer) for the most part. You also get the advantage of tried and true libraries for a lot of languages, which saves you from reinventing the wheel again. There are stable servers and usable clients to help you in development, and the documentation of the protocol is pretty good. Also using things like HTTP-Bind interfaces, you can basically use XMPP without keeping a connection open. All this flexibility has its use.