6 ms·

Unfortunately, the guy responds with his own misinformations. Google said: "For example, mobile has several requirements around bandwidth and battery that are

Unfortunately, the guy responds with his own misinformations. Google said: "For example, mobile has several requirements around bandwidth and battery that are simply not part of the standard" He says: "This glances over the the fact that the X in XMPP stands for eXtensible, which still results in proposals for new protocol extensions every month." His misinformation is this: XMPP is XML based. The bandwidth that Google most likely refers to is a result of verbosity of XML. You can't eliminate that by extending XMPP, something that a guy who serves on XMPP Council should know. The only way to fix that specific problem is to change the protocol. Which is what Google did. This is an example a bad advocacy: badmouthing companies that decided to no longer use something you work on. I also find troubling the pounding Google gets for every little mis-step. When it comes to using and promoting open technologies Google is seemingly from another planet compared to other tech giants (Apple, Microsoft, Facebook, Amazon, you name it). And yet the furor is not about Microsoft using completely secret protocol (Skype), not about Apple promising to publish their secret protocol (Facetime) and then not doing it, not about Apple preventing fair browser competition in iOS etc. but about Google no longer using XMPP. A lack of perspective.

rasterizer 13y ago
This. Chromium alone puts them in the plus column standard-wise. Usually apps are judged on merit, yet in Google's case there is the misconception that they have to defend every engineering decision they make. I don't see how this is a hot topic seeing as every other IM is an island, and quite frankly if it means directing more resources towards projects like Google Fiber, personally I think it's more than worth it to sunset GReader or move away from a limiting standard.
- threeseed 13y ago
  Sorry but NONE of what you said is true or frankly makes any sense. Chromium will likely be less standards based now that they don't have the tow of the other WebKit companies keeping them in check. Case in point: SPDY. Google is not the only company who has to defend every engineering decision. The reason it is being discussed is that it is fitting into this new narrative of Google being less interested in standards and more interested in their advertising centric walled garden. And finally Google can do multiple things at once. It isn't an either-or scenario.
  - traek 13y ago
    SPDY is an open protocol, and Google is working towards standardization of it. Plus, many other browsers have implementations of it based on Google's protocol specification, so it's not true that SPDY is an example of Google becoming less standards based.
    - threeseed 13y ago
      Exactly my point. Google develops a proprietary protocol without ANY consultation. They then leverage the fact that they own the world's biggest website and popular browser to force it by stealth into popularity. And then afterwards decide to work to standardising it despite it not necessarily being the optimum choice for everyone. The core protocols of the internet are fundamental. And they should be designed deliberately with as many parties as possible involved. This is not the way standards should come into existence.
      - rasterizer 13y ago
        I don't think you know what "proprietary" means, you don't pay Google to use SPDY. They solved a problem and made something better, case in point Facebook and Twitter among others have already deployed it. If you do some research you'll find that most standards started as projects that came out of a single company or lab that were later adopted by industry.
        threeseed 13y ago
        No. You don't understand what proprietary means. SPDY is a trademarked technology owned by a private corporation. The only reason companies are adopting SPDY is because it is an improvement than HTTP. SPDY is far from perfect. The issue is that with core internet protocols this is not the way it should happen.
        AnthonyMouse 13y ago
        >The only reason companies are adopting SPDY is because it is an improvement than HTTP. I don't see the problem. >The issue is that with core internet protocols this is not the way it should happen. This is exactly how it does happen. Someone creates something, people like it, the creators don't enforce patents on it or try to keep it a secret, someone writes it up into an RFC. That's how internet standards are created. That's how they've been created as long as there has been an internet. Look at a counterexample. Microsoft with OOXML. Here we have a so-called standard which says things like "do this the way X version of Microsoft Word does it" without actually specifying how to do it. It's not an open standard, it's a document claiming to be an open standard on paper so that Microsoft can claim their proprietary file format is an open standard. No one else is expected to use it for any purpose other than attempting interoperability with Microsoft Office and Microsoft has no particular interest in having anyone even succeed in doing that. SPDY is not that. Google has published a reference implementation with source code. People other than Google use it for reasons having nothing to do with interoperability and Google services continue to be available to browsers without SPDY. "They didn't ask permission first" is just disingenuous griping -- who are they even supposed to have asked? SPDY isn't a problem. Hangouts are. I don't see source code for a reference implementation. I don't see anyone but Google implementing the protocol. That's how you know something is wrong.
ralphm 13y ago
I should have made the link to the document on XMPP on Mobile Devices more explicit: http://xmpp.org/extensions/xep-0286.html http://xmpp.org/extensions/xep-0286.html. In short, the use of compression in the TLS layer negates the oft stated verbosity of XMPP. It really isn't the problem you think it is. More info: http://stpeter.im/journal/1384.html http://stpeter.im/journal/1384.html. I might be a fanboy, but I do know what I'm talking about.
- tytso 13y ago
  Compression doesn't help CPU utilization, which in turn doesn't help battery consumption. In addition, if the protocol is "chatty" (i.e., sends lots of packets even if there isn't any communication going on -- say, when users change their status/presence information, for example) it means waking up the CPU, which in turn means less power efficiency.
  - ralphm 13y ago
    Please read that first document and also my remark about SIFT, which basically allows for delaying or dropping presence to cut down on antenna use and battery consumption.
  - dwdbah 13y ago
    Hmmm... As the author of XEP-0286, I think I ought to chip in a bit. 1) Compression does help keep the transmissions under the FACH threshold on most networks. This more than outweighs the CPU cost. 2) The bulk of the data to be compressed isn't XML, but text. 3) The chattiness of the protocol - ie, transmissions that are not needed at that point in time - will indeed change radio states, but not only did Google tackle this problem privately, but the XSF has also looked at it in detail. 4) Really, the CPU is a non-issue here. It's all about the radio power states. This is likely to be entirely different at the server end, however efficient XML parsers can and do exist to mitigate this, and make it more distributable.
magic_haze 13y ago
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.
icebraining 13y ago
Nobody expects better from Microsoft, but they still expect better from Google, hence the sense of betrayal and subsequent furor.
- untog 13y ago
  That's exactly the point, though- why should Google have to defend themselves so much more? Apple have the most tightly locked in messaging protocol, but no-one says a word about them opening it- even after they promised to.
  - betterunix 13y ago
    Perhaps because nobody can seriously expect Apple to commit to openness (this is the company that forbids open source licenses in its app store), where Google was already using an open protocol?
    - mh- 13y ago
      I don't think Apple actually forbids open source from the app store, do they? As far as I understand/interpret their policy: they only prohibit so-called copyleft licenses, and/or ones which would be violated inherently by the app store's binary-only distribution model.
  - jsz0 13y ago
    I don't recall Apple ever promising that but if they did they wouldn't have explained why they can't or won't do it because they don't want to have it both ways. They are fine saying nope it's not open deal with it. Google seems to want it both ways which puts them under the microscope. Apple gets plenty of criticism from the same types of people for not being open. I don't buy into the poor lil' Google angle of this. They know exactly what they're doing.
    - nr0mx 13y ago
      "Upon the launch of the iPhone 4, Jobs promised that Apple would immediately start working with standards bodies to make the FaceTime protocol an "open standard." As of November 2012, it is not yet known to have been ratified by any standards body, and the extent of work by Apple with regard to this promise is unclear as Apple has not released technical specifications for the service. FaceTime is not currently supported on any non-Apple devices." http://en.wikipedia.org/wiki/FaceTime http://en.wikipedia.org/wiki/FaceTime
ghshephard 13y ago
Re: "His misinformation is this: XMPP is XML based. The bandwidth that Google most likely refers to is a result of verbosity of XML. You can't eliminate that by extending XMPP, something that a guy who serves on XMPP Council should know." He directly addresses the Bandwidth concern by noting that interoperability on the server side is irrelevant to mobile anyways: "Of course none of these concerns for mobile are applicable for server federation. As far as I know, the Google Talk client on Android doesn't even use XMPP as the client-to-server protocol."
jerf 13y ago
"You can't eliminate that by extending XMPP, something that a guy who serves on XMPP Council should know." Ehhh... well... if you're willing to put some work into the matter that may not be as true as you'd think. Yes, to speak the federated protocol to another server you're going to be speaking the XML protocol, but between a server and a client that come to accommodations with each other, you don't really have to speak XML. You'd want to speak something isomorphic to the XML, but the XMPP XML is not that verbose on a node-by-node basis or anything (minus a couple things, see below), it really is the XML, not the semantic content. It would be fairly easy for a medium-to-high skill developer to come up with an isomorphism for use with mobile clients. (It is sufficiently tricky that there would be a few traps that could catch the inexperienced or unwary (watch those namespaces!), but it isn't that difficult.) The end result is a more bandwidth efficient protocol that is a drop-in replacement at the XMPP library layer in the client for XMPP. (Of course, if your client is programmed to fling around XML all over the place internally this won't help, but, well, that's the price of failing to abstract properly.) Where you'd still have trouble is things like roster size, but yes, there are XEPs for that, and before long you're looking at a reasonably svelte protocol (not perfectly, but reasonably svelte) that is still largely XMPP and easy to write communication with the outside world. What's really difficult is semantic IM translation between entirely different systems, not protocol translation. ejabberd, the server whose internals I am most familiar with, essentially works by internally speaking Erlang terms with itself, and translating to the XML protocol only at the edges. It wouldn't be very hard to drop in different serialization at the edges and get a different protocol; as proof of concept of the fact this is possible, one could easily simply serialize those Erlang terms with Erlang's term serialization, and indeed, when operating ejabberd in a clustered mode, that's actually happening across the wire as the cluster nodes communicate with each other. However much effort that may be, it seems easier than starting from scratch.
- winter_blue 13y ago
  There are a whole bunch of competing binary XML formats that promise to be more efficient than XML (both in terms of space usage, and time taken to process/parse). See: http://en.wikipedia.org/wiki/Binary_XML http://en.wikipedia.org/wiki/Binary_XML Fast Infoset is a good contender: http://en.wikipedia.org/wiki/Fast_Infoset http://en.wikipedia.org/wiki/Fast_Infoset
shmerl 13y ago
The only way to fix that specific problem is to change the protocol. Which is what Google did. Creating new and better protocols is OK. Making them closed and non interoperable - is not. XMPP is not ideal, but it's open for participation in its development and for its usage. Whatever Google decided to create is not open, and that's their main failure.
sbuk 13y ago
Not a lack of perspective at all, more of an attempt at deflection because Google are being dicks. Skype's protocols predate Microsofts takeover, so attempting to 'blame' them is churlish, and there already has been a furore over Apple and FaceTime. The browser thing has absolutely sweet FA to do with this.
crsna 13y ago
The furor is not about dropping XMPP; it is about dropping the philosophy of open communication they championed: "Client Choice, Service Choice and Platform Choice" (https://developers.google.com/talk/open_communications https://developers.google.com/talk/open_communications). If Google chose to drop XMPP in favor of some other protocol that allowed others to adopt and interoperate, the discussion would have been about the effort required to migrate. But this move by Google is a huge blow to those who hoped for a world of ip based open communication solution. Google is in a position to define the course of internet and has used that power in several ways in the past. This move from an open communication network to a closed network, to me, is as defining as WebGL and WebRTC are, but in a very unhealthy way. Google's move therefore is clearly 'evil' (as per their own definition of evil) as it is a clear choice they made to safeguard their vested interests, stating that other corporations are unduly benefiting from their openness as a reason.(http://www.youtube.com/watch?v=AfK8h73bb-o http://www.youtube.com/watch?v=AfK8h73bb-o [2:40]) They stated that major networks did not interoperate with them. But in 2007 AIM started interoperating with Google Talk. http://gmailblog.blogspot.in/2007/12/gmail-chat-aim-crazy-delicious.html http://gmailblog.blogspot.in/2007/12/gmail-chat-aim-crazy-de.... Doesn't that count? What did Google do to promote federation, other than asking people to contact them to federate? It appears that when Google was small, they tried to be open to benefit from other big players. Now that they are the biggies, they don't see any value in being open. I believe more than any other company you mentioned, Google benefited significantly by projecting themselves as the messiahs of internet, purportedly promoting openness and standardization. They captured the imagination of people like us by promising to be only doers of good, placing the objectives of internet and humanity ahead of the corporation's benefits. They did so, as long as it worked in their favor. Those initial adopters who stood with them for these objectives are either absorbed into Google to work as if Google's interests are internet's interests or they are too few and left with fewer alternatives to significantly influence Google and its corporate objectives. With many of the influential personalities deeply affiliated with Google, we have fewer voices calling a spade as a spade.
- anoncow 13y ago
  > It appears that when Google was small, they tried to be open to benefit from other big players. Now that they are the biggies, they don't see any value in being open. Sad but true. Corporations who have to worry about keeping their share price forever in the green will have to compromise on their ideals. They will still talk about their ideals but they won't put their money where their mouth is.
anoncow 13y ago
>And yet the furor is not about Microsoft... The furore is partly also about Google moving away from an open protocol to a supposedly secret protocol. If Google were to publish the new protocol that Hangouts uses all/most of the animosity would vanish. And people would come up with a xmpp to hangouts bridge too. Google has supported and even championed open source initiatives and it has served them well. And imo it will serve them well in the long term if they continue being open, instead of trying to monopolize a segment of the market.
eunice 13y ago
Google have spent years building a brand out of how """open""" they are; a lot of their marketing/fud is based around it. Basically they co-opted the language of open source to rube nerds, while nobody is under any illusions re: Microsoft & Apple.

rasterizer 13y ago

This. Chromium alone puts them in the plus column standard-wise. Usually apps are judged on merit, yet in Google's case there is the misconception that they have to defend every engineering decision they make. I don't see how this is a hot topic seeing as every other IM is an island, and quite frankly if it means directing more resources towards projects like Google Fiber, personally I think it's more than worth it to sunset GReader or move away from a limiting standard.

threeseed 13y ago
Sorry but NONE of what you said is true or frankly makes any sense. Chromium will likely be less standards based now that they don't have the tow of the other WebKit companies keeping them in check. Case in point: SPDY. Google is not the only company who has to defend every engineering decision. The reason it is being discussed is that it is fitting into this new narrative of Google being less interested in standards and more interested in their advertising centric walled garden. And finally Google can do multiple things at once. It isn't an either-or scenario.
- traek 13y ago
  SPDY is an open protocol, and Google is working towards standardization of it. Plus, many other browsers have implementations of it based on Google's protocol specification, so it's not true that SPDY is an example of Google becoming less standards based.
  - threeseed 13y ago
    Exactly my point. Google develops a proprietary protocol without ANY consultation. They then leverage the fact that they own the world's biggest website and popular browser to force it by stealth into popularity. And then afterwards decide to work to standardising it despite it not necessarily being the optimum choice for everyone. The core protocols of the internet are fundamental. And they should be designed deliberately with as many parties as possible involved. This is not the way standards should come into existence.
    - rasterizer 13y ago
      I don't think you know what "proprietary" means, you don't pay Google to use SPDY. They solved a problem and made something better, case in point Facebook and Twitter among others have already deployed it. If you do some research you'll find that most standards started as projects that came out of a single company or lab that were later adopted by industry.
      - threeseed 13y ago
        No. You don't understand what proprietary means. SPDY is a trademarked technology owned by a private corporation. The only reason companies are adopting SPDY is because it is an improvement than HTTP. SPDY is far from perfect. The issue is that with core internet protocols this is not the way it should happen.
        AnthonyMouse 13y ago
        >The only reason companies are adopting SPDY is because it is an improvement than HTTP. I don't see the problem. >The issue is that with core internet protocols this is not the way it should happen. This is exactly how it does happen. Someone creates something, people like it, the creators don't enforce patents on it or try to keep it a secret, someone writes it up into an RFC. That's how internet standards are created. That's how they've been created as long as there has been an internet. Look at a counterexample. Microsoft with OOXML. Here we have a so-called standard which says things like "do this the way X version of Microsoft Word does it" without actually specifying how to do it. It's not an open standard, it's a document claiming to be an open standard on paper so that Microsoft can claim their proprietary file format is an open standard. No one else is expected to use it for any purpose other than attempting interoperability with Microsoft Office and Microsoft has no particular interest in having anyone even succeed in doing that. SPDY is not that. Google has published a reference implementation with source code. People other than Google use it for reasons having nothing to do with interoperability and Google services continue to be available to browsers without SPDY. "They didn't ask permission first" is just disingenuous griping -- who are they even supposed to have asked? SPDY isn't a problem. Hangouts are. I don't see source code for a reference implementation. I don't see anyone but Google implementing the protocol. That's how you know something is wrong.

ralphm 13y ago

I should have made the link to the document on XMPP on Mobile Devices more explicit: http://xmpp.org/extensions/xep-0286.html http://xmpp.org/extensions/xep-0286.html. In short, the use of compression in the TLS layer negates the oft stated verbosity of XMPP. It really isn't the problem you think it is. More info: http://stpeter.im/journal/1384.html http://stpeter.im/journal/1384.html. I might be a fanboy, but I do know what I'm talking about.

tytso 13y ago
Compression doesn't help CPU utilization, which in turn doesn't help battery consumption. In addition, if the protocol is "chatty" (i.e., sends lots of packets even if there isn't any communication going on -- say, when users change their status/presence information, for example) it means waking up the CPU, which in turn means less power efficiency.
- ralphm 13y ago
  Please read that first document and also my remark about SIFT, which basically allows for delaying or dropping presence to cut down on antenna use and battery consumption.
- dwdbah 13y ago
  Hmmm... As the author of XEP-0286, I think I ought to chip in a bit. 1) Compression does help keep the transmissions under the FACH threshold on most networks. This more than outweighs the CPU cost. 2) The bulk of the data to be compressed isn't XML, but text. 3) The chattiness of the protocol - ie, transmissions that are not needed at that point in time - will indeed change radio states, but not only did Google tackle this problem privately, but the XSF has also looked at it in detail. 4) Really, the CPU is a non-issue here. It's all about the radio power states. This is likely to be entirely different at the server end, however efficient XML parsers can and do exist to mitigate this, and make it more distributable.

magic_haze 13y ago

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.

icebraining 13y ago

Nobody expects better from Microsoft, but they still expect better from Google, hence the sense of betrayal and subsequent furor.

untog 13y ago
That's exactly the point, though- why should Google have to defend themselves so much more? Apple have the most tightly locked in messaging protocol, but no-one says a word about them opening it- even after they promised to.
- betterunix 13y ago
  Perhaps because nobody can seriously expect Apple to commit to openness (this is the company that forbids open source licenses in its app store), where Google was already using an open protocol?
  - mh- 13y ago
    I don't think Apple actually forbids open source from the app store, do they? As far as I understand/interpret their policy: they only prohibit so-called copyleft licenses, and/or ones which would be violated inherently by the app store's binary-only distribution model.
- jsz0 13y ago
  I don't recall Apple ever promising that but if they did they wouldn't have explained why they can't or won't do it because they don't want to have it both ways. They are fine saying nope it's not open deal with it. Google seems to want it both ways which puts them under the microscope. Apple gets plenty of criticism from the same types of people for not being open. I don't buy into the poor lil' Google angle of this. They know exactly what they're doing.
  - nr0mx 13y ago
    "Upon the launch of the iPhone 4, Jobs promised that Apple would immediately start working with standards bodies to make the FaceTime protocol an "open standard." As of November 2012, it is not yet known to have been ratified by any standards body, and the extent of work by Apple with regard to this promise is unclear as Apple has not released technical specifications for the service. FaceTime is not currently supported on any non-Apple devices." http://en.wikipedia.org/wiki/FaceTime http://en.wikipedia.org/wiki/FaceTime

ghshephard 13y ago

Re: "His misinformation is this: XMPP is XML based. The bandwidth that Google most likely refers to is a result of verbosity of XML. You can't eliminate that by extending XMPP, something that a guy who serves on XMPP Council should know." He directly addresses the Bandwidth concern by noting that interoperability on the server side is irrelevant to mobile anyways: "Of course none of these concerns for mobile are applicable for server federation. As far as I know, the Google Talk client on Android doesn't even use XMPP as the client-to-server protocol."

jerf 13y ago

"You can't eliminate that by extending XMPP, something that a guy who serves on XMPP Council should know." Ehhh... well... if you're willing to put some work into the matter that may not be as true as you'd think. Yes, to speak the federated protocol to another server you're going to be speaking the XML protocol, but between a server and a client that come to accommodations with each other, you don't really have to speak XML. You'd want to speak something isomorphic to the XML, but the XMPP XML is not that verbose on a node-by-node basis or anything (minus a couple things, see below), it really is the XML, not the semantic content. It would be fairly easy for a medium-to-high skill developer to come up with an isomorphism for use with mobile clients. (It is sufficiently tricky that there would be a few traps that could catch the inexperienced or unwary (watch those namespaces!), but it isn't that difficult.) The end result is a more bandwidth efficient protocol that is a drop-in replacement at the XMPP library layer in the client for XMPP. (Of course, if your client is programmed to fling around XML all over the place internally this won't help, but, well, that's the price of failing to abstract properly.) Where you'd still have trouble is things like roster size, but yes, there are XEPs for that, and before long you're looking at a reasonably svelte protocol (not perfectly, but reasonably svelte) that is still largely XMPP and easy to write communication with the outside world. What's really difficult is semantic IM translation between entirely different systems, not protocol translation. ejabberd, the server whose internals I am most familiar with, essentially works by internally speaking Erlang terms with itself, and translating to the XML protocol only at the edges. It wouldn't be very hard to drop in different serialization at the edges and get a different protocol; as proof of concept of the fact this is possible, one could easily simply serialize those Erlang terms with Erlang's term serialization, and indeed, when operating ejabberd in a clustered mode, that's actually happening across the wire as the cluster nodes communicate with each other. However much effort that may be, it seems easier than starting from scratch.

winter_blue 13y ago
There are a whole bunch of competing binary XML formats that promise to be more efficient than XML (both in terms of space usage, and time taken to process/parse). See: http://en.wikipedia.org/wiki/Binary_XML http://en.wikipedia.org/wiki/Binary_XML Fast Infoset is a good contender: http://en.wikipedia.org/wiki/Fast_Infoset http://en.wikipedia.org/wiki/Fast_Infoset

shmerl 13y ago

The only way to fix that specific problem is to change the protocol. Which is what Google did. Creating new and better protocols is OK. Making them closed and non interoperable - is not. XMPP is not ideal, but it's open for participation in its development and for its usage. Whatever Google decided to create is not open, and that's their main failure.

sbuk 13y ago

Not a lack of perspective at all, more of an attempt at deflection because Google are being dicks. Skype's protocols predate Microsofts takeover, so attempting to 'blame' them is churlish, and there already has been a furore over Apple and FaceTime. The browser thing has absolutely sweet FA to do with this.

crsna 13y ago

The furor is not about dropping XMPP; it is about dropping the philosophy of open communication they championed: "Client Choice, Service Choice and Platform Choice" (https://developers.google.com/talk/open_communications https://developers.google.com/talk/open_communications). If Google chose to drop XMPP in favor of some other protocol that allowed others to adopt and interoperate, the discussion would have been about the effort required to migrate. But this move by Google is a huge blow to those who hoped for a world of ip based open communication solution. Google is in a position to define the course of internet and has used that power in several ways in the past. This move from an open communication network to a closed network, to me, is as defining as WebGL and WebRTC are, but in a very unhealthy way. Google's move therefore is clearly 'evil' (as per their own definition of evil) as it is a clear choice they made to safeguard their vested interests, stating that other corporations are unduly benefiting from their openness as a reason.(http://www.youtube.com/watch?v=AfK8h73bb-o http://www.youtube.com/watch?v=AfK8h73bb-o [2:40]) They stated that major networks did not interoperate with them. But in 2007 AIM started interoperating with Google Talk. http://gmailblog.blogspot.in/2007/12/gmail-chat-aim-crazy-delicious.html http://gmailblog.blogspot.in/2007/12/gmail-chat-aim-crazy-de.... Doesn't that count? What did Google do to promote federation, other than asking people to contact them to federate? It appears that when Google was small, they tried to be open to benefit from other big players. Now that they are the biggies, they don't see any value in being open. I believe more than any other company you mentioned, Google benefited significantly by projecting themselves as the messiahs of internet, purportedly promoting openness and standardization. They captured the imagination of people like us by promising to be only doers of good, placing the objectives of internet and humanity ahead of the corporation's benefits. They did so, as long as it worked in their favor. Those initial adopters who stood with them for these objectives are either absorbed into Google to work as if Google's interests are internet's interests or they are too few and left with fewer alternatives to significantly influence Google and its corporate objectives. With many of the influential personalities deeply affiliated with Google, we have fewer voices calling a spade as a spade.

anoncow 13y ago
> It appears that when Google was small, they tried to be open to benefit from other big players. Now that they are the biggies, they don't see any value in being open. Sad but true. Corporations who have to worry about keeping their share price forever in the green will have to compromise on their ideals. They will still talk about their ideals but they won't put their money where their mouth is.

anoncow 13y ago

>And yet the furor is not about Microsoft... The furore is partly also about Google moving away from an open protocol to a supposedly secret protocol. If Google were to publish the new protocol that Hangouts uses all/most of the animosity would vanish. And people would come up with a xmpp to hangouts bridge too. Google has supported and even championed open source initiatives and it has served them well. And imo it will serve them well in the long term if they continue being open, instead of trying to monopolize a segment of the market.

eunice 13y ago

Google have spent years building a brand out of how """open""" they are; a lot of their marketing/fud is based around it. Basically they co-opted the language of open source to rube nerds, while nobody is under any illusions re: Microsoft & Apple.