5 ms·

Really? There are plenty of valid reasons why XMPP is not suitable for mobile usage (most notably, the proprietary push notification systems that all platforms

Really? There are plenty of valid reasons why XMPP is not suitable for mobile usage (most notably, the proprietary push notification systems that all platforms insist you have to use), but XML isn't one of them. If you use TLS with XMPP (as gtalk does [1]), you get the compression protocol for free, but even if you can't, there's XEP-0138 [2], which specifies the use of zlib and has been in development for over 12 years now, and finalized since 2009. XML is fugly, but it works. At the scale Google operates, it is laughable that the use of XML in chat protocols could possibly impact their bandwidth accounting. [1] https://developers.google.com/talk/open_communications#developer https://developers.google.com/talk/open_communications#devel... [2] http://xmpp.org/extensions/xep-0138.html http://xmpp.org/extensions/xep-0138.html

thrownaway2424 13y ago
zlib-compressed XML cannot hold a candle to protocol buffers in the department of space efficiency.
- nextweek2 13y ago
  Indeed, its the wrong tool for the job. EXI compressions would be better. http://www.w3.org/XML/EXI/ http://www.w3.org/XML/EXI/ http://exificient.sourceforge.net/?id=performance http://exificient.sourceforge.net/?id=performance http://xmpp.org/extensions/xep-0322.html http://xmpp.org/extensions/xep-0322.html
jallmann 13y ago
It's not just bandwidth, but the cost to process that XML, which is very expensive compared to other serialization formats. Then there are a whole host of other concerns that result from XML being text-based (cdata, preventing runaway parsing, etc). Not defending what Google has done, but the reality is XMPP is simply the most common among a lineup of really crappy chat/presence protocols. Now, XML itself is one problem, but the "culture" (eg, usage norms) around XML is another -- much like Java's cultural preoccupation with abstraction and boilerplate, XML-based formats have a tendency to veer towards the unwieldy and verbose. XMPP is no exception. While XMPP has been instrumental in propagating standardized presence and IM, its age is showing. Unless we develop a modern, open replacement that is natively suited to the needs of today's Internet (voice, video, file transfer, group messaging, etc+), we will see companies continue to develop proprietary solutions that are locked behind walled gardens. +XEPs and extensions are insufficient; too many optional extensions hinders interop and contorts the system beyond its original design specifications. Just ask anyone who's tried to implement chat/buddylists on top of SIP presence.
- nacs 13y ago
  Sorry but I just don't see how bandwidth and XML could ever be a problem for Google. Youtube alone makes up a significant amount of the Internet's total traffic. Sending compressed XML isn't a problem for Google.
  - jallmann 13y ago
    Just because Google has a lot of capacity doesn't mean they're wasteful with it. At scale, minor inefficiencies add up to a lot. That is the incentive for protobufs, etc. For a more concrete example of seemingly trivial bandwidth savings, check out the HTML source to their 404 page (it validates!): http://www.google.com/asdf.html http://www.google.com/asdf.html
    - huxley 13y ago
      That 404 page is a relic from the past. Take a look at what makes up their search page and you'll see that it is almost 1 MB uncompressed. That's for a page that displays a logo, a navbar, a text input and a button. Sure, the page has really become a one-page app with some advantages that come from pre-loading, but jeez, it is still 1MB!
  - hahainternet 13y ago
    > Sorry but I just don't see how bandwidth and XML could ever be a problem for Google. Then why comment? If you have nothing to input from either side. Doubt is not a valuable commodity.
    - nsomaru 13y ago
      We not here for the sole reason of providing value to you. Although we may, incidentally, hope to do so. Some of us need our thoughts clarified by the community. In any case, I find that learning happens in an atmosphere of uncertainty, humility and exploration. Doubt, thus, is a valuable commodity in any community which encourages learning, and I'd like to believe HN is one of them.
    - 13y ago
dmayle 13y ago
Disclaimer: I am a Google employee, but I do not speak for Google. I'm not offering an opinion for or against the decision to drop XMPP, but I wanted to offer some corrections to what is being said. I think you've misunderstood how scale works. At scale, problems do not shrink, they grow. I do not work on anything even closely related to Hangouts, but I used to run an ejabberd server myself, and I've worked with SIP a bit. XML does have problems, both with bandwidth, (even compressed), high CPU utilization, parsing code is more complex (which leads to more security issues). XMPP also has issues, and I'm not just talking about how hard it is to get multiple Audio/Video clients to communicate[1]. (e.g. kernel resources, the incredible number of failure states, etc.) Cheers, Doug #1 At least early versions of iChat used XMPP with SIP. For those who don't know SIP, it stands for Session Initiation Protocol, which means that it doesn't transfer the audio/video, it's just a language for making connections. You have to negotiate a transport layer (which was often but not always RTP or SRTP). You have to exchange connection ports via SDP. If you're lucky and manage to get by all firewalls at this point, you now have to hope you're able to use compatible codecs. Interoperability was a nightmare.
- greggman 13y ago
  And yet google wave ran on xmpp which was arguably a far far more sophisticated app doing way more communication than just chat
  - josephg 13y ago
    Google wave only used XMPP for federation. It was a nightmare to deploy and we never got it working reliably. Different jabber servers all had different quirks or implemented subsets of the XMPP extension spec. The client-server protocol was simply JSON. XMPP was not involved. (Well, we translated protobuf messages to JSON, so it was ugly JSON, but still JSON).
    - mh- 13y ago
      (if you can't comment on this, no worries. thanks) we translated protobuf messages to JSON just curious- is this the same 'protojson' I see exchanged in the current crop of APIs? aside, any opinions on others choosing that as a standard way of communicating between internal services on disparate runtimes? (golang<->python, for example) -- edit: offtopic, thanks for ShareJS.

thrownaway2424 13y ago

zlib-compressed XML cannot hold a candle to protocol buffers in the department of space efficiency.

nextweek2 13y ago
Indeed, its the wrong tool for the job. EXI compressions would be better. http://www.w3.org/XML/EXI/ http://www.w3.org/XML/EXI/ http://exificient.sourceforge.net/?id=performance http://exificient.sourceforge.net/?id=performance http://xmpp.org/extensions/xep-0322.html http://xmpp.org/extensions/xep-0322.html

jallmann 13y ago

It's not just bandwidth, but the cost to process that XML, which is very expensive compared to other serialization formats. Then there are a whole host of other concerns that result from XML being text-based (cdata, preventing runaway parsing, etc). Not defending what Google has done, but the reality is XMPP is simply the most common among a lineup of really crappy chat/presence protocols. Now, XML itself is one problem, but the "culture" (eg, usage norms) around XML is another -- much like Java's cultural preoccupation with abstraction and boilerplate, XML-based formats have a tendency to veer towards the unwieldy and verbose. XMPP is no exception. While XMPP has been instrumental in propagating standardized presence and IM, its age is showing. Unless we develop a modern, open replacement that is natively suited to the needs of today's Internet (voice, video, file transfer, group messaging, etc+), we will see companies continue to develop proprietary solutions that are locked behind walled gardens. +XEPs and extensions are insufficient; too many optional extensions hinders interop and contorts the system beyond its original design specifications. Just ask anyone who's tried to implement chat/buddylists on top of SIP presence.

nacs 13y ago
Sorry but I just don't see how bandwidth and XML could ever be a problem for Google. Youtube alone makes up a significant amount of the Internet's total traffic. Sending compressed XML isn't a problem for Google.
- jallmann 13y ago
  Just because Google has a lot of capacity doesn't mean they're wasteful with it. At scale, minor inefficiencies add up to a lot. That is the incentive for protobufs, etc. For a more concrete example of seemingly trivial bandwidth savings, check out the HTML source to their 404 page (it validates!): http://www.google.com/asdf.html http://www.google.com/asdf.html
  - huxley 13y ago
    That 404 page is a relic from the past. Take a look at what makes up their search page and you'll see that it is almost 1 MB uncompressed. That's for a page that displays a logo, a navbar, a text input and a button. Sure, the page has really become a one-page app with some advantages that come from pre-loading, but jeez, it is still 1MB!
- hahainternet 13y ago
  > Sorry but I just don't see how bandwidth and XML could ever be a problem for Google. Then why comment? If you have nothing to input from either side. Doubt is not a valuable commodity.
  - nsomaru 13y ago
    We not here for the sole reason of providing value to you. Although we may, incidentally, hope to do so. Some of us need our thoughts clarified by the community. In any case, I find that learning happens in an atmosphere of uncertainty, humility and exploration. Doubt, thus, is a valuable commodity in any community which encourages learning, and I'd like to believe HN is one of them.
  - 13y ago

dmayle 13y ago

Disclaimer: I am a Google employee, but I do not speak for Google. I'm not offering an opinion for or against the decision to drop XMPP, but I wanted to offer some corrections to what is being said. I think you've misunderstood how scale works. At scale, problems do not shrink, they grow. I do not work on anything even closely related to Hangouts, but I used to run an ejabberd server myself, and I've worked with SIP a bit. XML does have problems, both with bandwidth, (even compressed), high CPU utilization, parsing code is more complex (which leads to more security issues). XMPP also has issues, and I'm not just talking about how hard it is to get multiple Audio/Video clients to communicate[1]. (e.g. kernel resources, the incredible number of failure states, etc.) Cheers, Doug #1 At least early versions of iChat used XMPP with SIP. For those who don't know SIP, it stands for Session Initiation Protocol, which means that it doesn't transfer the audio/video, it's just a language for making connections. You have to negotiate a transport layer (which was often but not always RTP or SRTP). You have to exchange connection ports via SDP. If you're lucky and manage to get by all firewalls at this point, you now have to hope you're able to use compatible codecs. Interoperability was a nightmare.

greggman 13y ago
And yet google wave ran on xmpp which was arguably a far far more sophisticated app doing way more communication than just chat
- josephg 13y ago
  Google wave only used XMPP for federation. It was a nightmare to deploy and we never got it working reliably. Different jabber servers all had different quirks or implemented subsets of the XMPP extension spec. The client-server protocol was simply JSON. XMPP was not involved. (Well, we translated protobuf messages to JSON, so it was ugly JSON, but still JSON).
  - mh- 13y ago
    (if you can't comment on this, no worries. thanks) we translated protobuf messages to JSON just curious- is this the same 'protojson' I see exchanged in the current crop of APIs? aside, any opinions on others choosing that as a standard way of communicating between internal services on disparate runtimes? (golang<->python, for example) -- edit: offtopic, thanks for ShareJS.