11 ms·

Google defends dropping chat federation with inaccurate comments

175 points by AndrewDucker 13y ago

hayksaakian 13y ago
It was ultimately a business decision - the same kind that leads to product shutdowns and all the other "evil" things that new Google does.
- ralphm 13y ago
  That is perfectly valid, to me. However, there is no reason to spread misinformation to cover such a decision and to bluntly cut off existing communications between people outside and inside of the Google Hangout domains. Without any warning to the former, even.
- kyrra 13y ago
  A lot of the shutdowns have been due to low (for google) user bases, or just no engineering staff to support it. A lot of their shutdowns I see as a way for google to become more focused as a company, which I feel like was needed. They had too many half-baked services. As for XMPP, it was their business decision. I'm betting engineering had a good reason for it, it just may not be shared with us.
- steveklabnik 13y ago
  Oh, a _business_ decision. I guess we can just let them continue to embrace, extend, and extinguish the commons we've built over the last decades, then. No complaints necessary. (I'm not a GOOG shareholder, so their business needs don't matter to me. I _am_ now going to be cut off from my contacts, though. Part of markets is the feedback that comes with mis-steps, and saying "it's just business" does a dis-service to those of us who feel that Google has been over-stepping their bounds.)
  - icebraining 13y ago
    The [EEE] strategy's three phases are: Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the 'simple' standard. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions. How does this fit in with what Google is doing? Where are their non-standard extensions to XMPP (or RSS, etc) that weren't supported by the competition? XMPP was essentially a non-player before Google used it, and it'll return to being a non-player after they leave. There's no big strategy needed to accomplish this. This is not to say I support Google's recent decisions, but then again, I had already moved off their applications (Reader and Gmail) way before the shutdowns started, mostly due to the methods used to push Chrome.
    - steveklabnik 13y ago
      They embraced standards via XMPP. They then extended them in proprietary ways, with Hangouts rather than gtalk. They then are deprecating gtalk in favor of Hangouts, and will finally extinguish it.
      - jmillikin 13y ago
        Hangouts is not an extension of XMPP, it is a replacement. Google's extensions to XMPP took place via the XEP process, and were published so other vendors could implement them.
        zobzu 13y ago
        That's exactly the same thing. Once you own most of the implementations running "the standard" you modify it and close it so that nobody can follow your path. It does not matter if the said modifications are called "G-XMPP" or 'Hangouts'. The result and logic are the same. The rest is a useless fight on semantics.
        jmillikin 13y ago
        The Hangouts protocol is not a modified or closed version of XMPP. They have nothing in common except that they're both used to implement IM clients. SSH is not an extended version of Telnet.
        zobzu 13y ago
        And then again.. you didn't get the point. SSH and Telnet do the same thing, but nobody killed off telnet by getting everyone to use their implementation of it, then kill it and propose SSH as alternative. Thats what Hangout does. Name 5 of your friends without a google account who use internet & mobile phones. See what I mean? They were using XMPP. Everyone could talk to them using XMPP. Not anymore. Wanna talk to them? Gotta use hangout, no way around it. It does not matter if its based on the same _code_ what matter is that it offers the same functionality AND kills off the previous product by using their market share. That's the freaking concept.
dvt 13y ago
Really? Can you so harshly judge Google on abandoning a (lets face it) terrible protocol? Maybe I could get over the fact that it's so complex -- which puts an unnecessary strain on both servers and clients -- and maybe I could get over the fact that (on average) servers consume 40% more memory than their IRC counterparts. Maybe I could even get over the fact that the spec could change at any moment (the eXtensible nature of it isn't necessarily a good thing, you know). But what I couldn't possibly in a million years get over is that... it's XML (shudder). -- To the downvoters: Here's some previous discussion about why XMPP sucks: https://news.ycombinator.com/item?id=2069810 https://news.ycombinator.com/item?id=2069810 I'm currently working on a project that deals with real time communication (think IRC for the new web) and after fidgeting around with XMPP for a couple of weeks, I gave up on it completely. It's awful. I doubt many people have implemented an XMPP client (or even worse.. a server). Try it some time.
- aimatt 13y ago
  I understand the frustration of working with a fat protocol. What is a viable, open alternative though?
  - dvt 13y ago
    IRC! :P Seriously though, there isn't a light one afaik. I ended up making my own -- I based it on IRC but wrapped it in JSON. It's stupid simple because chat should be easy.
    - dublinben 13y ago
      IRC is so lightweight, it's what NASA uses for their antarctic weather flights. http://arstechnica.com/information-technology/2013/01/antarctic-irc-how-nasas-flying-lab-stays-connected/ http://arstechnica.com/information-technology/2013/01/antarc...
      - mh- 13y ago
        antarctic satellite IRC? best i:line ever.
davorak 13y ago
> All that talk about Client Choice, Service Choice and Platform Choice has been replaced with "if the other big players don't play, why should we?". It seems like the impact of the other big players not playing is down played here. Did it not allow facebook users to start conversations with google talk users but not vice versa? Playing the cooperation card first is what google did, but in the iterated prisoners dilemma you often need to play the non-cooperative card if that is what your peers are doing. That really seemed to be the core of the issue. Now 5-25 years from now maybe google will have an entrenched culture of playing the non-cooperative card and will not reach for the cooperative card first but I do not judge this to be the case yet.
- ralphm 13y ago
  I believe I get to downplay that because the federation they joined helped grow their own network, and allowed them to do Google Talk for other domains. I know many companies that have moved their XMPP stuff to Google for that. Now those outside contacts are cut off, without any warning. Worse, they see their inside contacts online, can send them messages that never show up in Hangouts! Those big players are hardly affected, though. Also, Google could simply block those entities that don't fully federate (only).
  - BarkMore 13y ago
    I believe I get to downplay that because the federation they joined helped grow their own network Do you have any evidence that federation helped Google grow the network in a significant way? allowed them to do Google Talk for other domains Are you referring to Google Talk integration with Google Apps For Your Domain? Outside evidence suggests that federation is not used between these domains. For example XMPP SRV records are not required and ignored if present.
- threeseed 13y ago
  There are a few examples though where Google has opted not to support or develop standards. For example WebM, SPDY and XMPP and not to mention their continued support for Motorola's despicable FRAND abuses.
kkowalczyk 13y ago
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.
fakeer 13y ago
1. Microsoft/Facebook (and maybe more corporates) didn't play by the rules. They don't believe in "give and take", they just do "take, take,..". Google didn't like it so walked out. Instead of showing the sportsman's spirit and instead d of carried on despite of all the follies they simply left having pissed off. Good decision. 2. Universities, organisations? The number is too small to be bothered about, esp when compared with the likes of the two above^. They would rather innovate and try to lock-in users into their own platforms rather than hoping someday Cuck might turn the benevolent saint. 3. Whatever you say but unless you are short of manpower and talent it's actually easier difficult to innovate in-house sth proprietary and not when you've to conform to a "standard" and that too when the rewards are [1]. 4. Even I don't like the move but it was a business decision and this one made a lot more sense than killing off GR. The surprising fact here is, we hardly see anyone criticizing the providers that chose not to share back. We, keep on saying "no problems with XMPP" and "even though MS and Fb were not giving back, Google should have just let them free-load after all it's a do no eveil corp". Huh.
- ralphm 13y ago
  At least Microsoft has XMPP federation support in Lync: http://en.wikipedia.org/wiki/Microsoft_Lync_Server#XMPP http://en.wikipedia.org/wiki/Microsoft_Lync_Server#XMPP. Otherwise, yes, Skype and Facebook should add federation support. The actual protocol isn't even that important, as long it can be implemented freely.
- onedev 13y ago
  I'm interested in how you think MSFT and FB just "took, took, took..."
  - fakeer 13y ago
    Thank you for asking. Seems you have not been paying attention recently. Certainly not in the contxt of microsoft+facebook+gtalk+xmpp+google+talk one way, just google it; but that's my assumption. This is what I meant by "took...3 times". If it was sth else you wanted to know or were referring to then I obviously failed to grok that and you'll have to help me understand.
kmasters 13y ago
Isn't there a better question to be asked here? Federation is supposed to enable, well, federation. Google is not preventing XMPP federation in any way. Google is not "shutting down" XMPP or killing it. Why is Google the company important to the XMPP community? I scarcely see that it should matter. Open protocols are not exclusive clubs or infinite universes, anyone can opt in or out at any time, the rest of us will live. I think its great when big companies such as Google or whoever participate in open standards, but I also appreciate that they are in the business of providing the best product for their users (in their eyes) and are free to do what they want. When they do participate, we are getting a gift from them. Its not their obligation, right or even necessarily to their benefit. When they find other priorities fine, maybe someone more committed will move the project forward. And in other cases their NON-participation can be a gift as well. So whats the big deal?
- Macha 13y ago
  Google Talk was the largest federated XMPP server, and it provided an easy way for people using XMPP to talk to non-technical users. "I'll add you on XMPP" = blank stares, "I'll add you on Google Talk, just use your Gmail account" works, even if you yourself are not using Google Talk.
jjuliano 13y ago
The problem with XMPP is that it requires several open ports (5222, 5223, 5269, 5298, 8010) on the client, on the technical and practical standpoint the reason why XMPP is unpopular to big players because many businesses won't be bothered to open their ports, now if you are a solutions provider creating software for XMPP solutions for those companies, the most viable solution is to use BOSH to direct XMPP traffic to port 80, but there's another big problem, the only available BOSH library is a GPL BOSH library that you would license in order for you to not to ship your software along with it's source-code. Now if you can do the same thing over HTTP 1.1 stream, why bother with XMPP?
- BarkMore 13y ago
  * The problem with XMPP is that it requires several open ports (5222, 5223, 5269, 5298, 8010) on the client.* XMPP does not require any open ports on a client.
  - jjuliano 13y ago
    On the server, I mean. source: I'm an ex-cofounder of a now very successful syncing solution startup who uses XMPP and I wrote the initial server and client code.
- mh- 13y ago
  I have no idea where you got the idea about binding all (any) of those listening ports on the client, but that is incorrect. anecdotally: % lsof -i4 -T s COMMAND PID USER FD TYPE DEVICE imagent 158 mh 6u IPv4 0x2969ca78b2e9b6bb 0t0 TCP mac:52812->pb-in-f125.1e100.net:5223 (ESTABLISHED) authoritatively: http://wiki.xmpp.org/web/SRV_Records#Ports http://wiki.xmpp.org/web/SRV_Records#Ports
  - jjuliano 13y ago
    * On the server.
- deleted 13y ago
  [deleted]
rakeshpai 13y ago
I think I might have 2c to clarify the OP's stand, having worked on a mobile XMPP client before. This is with regards to his point about bandwidth and battery usage on mobile. XMPP is a connection-oriented stateful protocol. The connection setup process is very expensive: Connect, authenticate, advertise the list of supported client features, get the roster (contacts), and IIRC presence exchange, etc. Therefore, once you've established a connection, you really don't want it to break. Even just reconnecting is very expensive. However, in the mobile scenario, regular connection breakage is the norm. What most mobile based clients will then do is proxy the XMPP connection on the server-side and connect to the client over HTTP instead. This is well defined in the BoSH spec (XEP:124). BoSH was originally designed for web-based clients, but happens to meet the need of the mobile use-case. However, when it comes down to implementation, there are several optimizations that can be applied: 1. The roster exchange at the connection time is very expensive, and usually only sends data to the client that the client probably has already stored locally from a pervious session. Connection overhead can be reduced drastically if there was some way of versioning the roster and only transferring deltas. This was the OP was referring to. (Roster versioning, XEP:273). 2. Presence packets are one of the most chatty aspects of the protocol (x went offline, x is now online, etc). I've heard someone say that it constitutes about 80% of the packets on a typical connection, but this is anecdotal. In cases where the user isn't actively interacting with the client, having presence packets being sent all the time seems wasteful. One way to tackle this is to buffer up and de-duplicate the presence packets on the server, and send them in batches only when necessary. (For example, if x goes online, then offline, then online again, and then goes 'busy', the client only needs to know that x is busy.) I think this is what the OP was referring to when he mentioned the google:queue for delayed presence delivery. This alone can be a huge win for battery and bandwidth, since transferring data and processing it can be reduced drastically. Aside: Presence is so chatty, that some mobile clients simply don't handle presence at all. Take WhatsApp for example. It doesn't show whether every person in your list of contacts is online. The assumption is that every user is online by the nature of the device, and this assumption works in the common cases. In the edge cases is where you'd need to buffer up messages. This reduces chattiness drastically, making the protocol seem much more lightweight. (WhatsApp is based on XMPP, but have spun it off into their own thing.) Just thought I'd add these points to the discussion here, since there seemed to be some lack of understanding of the protocol. IMHO, the XML, as verbose as it is, isn't really the problem. The protocol itself is verbose and whether the transport uses XML or whatever else is of comparatively little consequence. This verbosity of the protocol (and not so much the format of data transfer) has its effect on battery life and bandwidth usage.
newman314 13y ago
If the issue is with mobile, why not build a MQTT <-> XMPP bridge or just support MQTT as an alternate protocol? http://en.wikipedia.org/wiki/MQ_Telemetry_Transport http://en.wikipedia.org/wiki/MQ_Telemetry_Transport

175 points by AndrewDucker 13y ago

It was ultimately a business decision - the same kind that leads to product shutdowns and all the other "evil" things that new Google does.

ralphm 13y ago
That is perfectly valid, to me. However, there is no reason to spread misinformation to cover such a decision and to bluntly cut off existing communications between people outside and inside of the Google Hangout domains. Without any warning to the former, even.
kyrra 13y ago
A lot of the shutdowns have been due to low (for google) user bases, or just no engineering staff to support it. A lot of their shutdowns I see as a way for google to become more focused as a company, which I feel like was needed. They had too many half-baked services. As for XMPP, it was their business decision. I'm betting engineering had a good reason for it, it just may not be shared with us.
steveklabnik 13y ago
Oh, a _business_ decision. I guess we can just let them continue to embrace, extend, and extinguish the commons we've built over the last decades, then. No complaints necessary. (I'm not a GOOG shareholder, so their business needs don't matter to me. I _am_ now going to be cut off from my contacts, though. Part of markets is the feedback that comes with mis-steps, and saying "it's just business" does a dis-service to those of us who feel that Google has been over-stepping their bounds.)
- icebraining 13y ago
  The [EEE] strategy's three phases are: Embrace: Development of software substantially compatible with a competing product, or implementing a public standard. Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the 'simple' standard. Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions. How does this fit in with what Google is doing? Where are their non-standard extensions to XMPP (or RSS, etc) that weren't supported by the competition? XMPP was essentially a non-player before Google used it, and it'll return to being a non-player after they leave. There's no big strategy needed to accomplish this. This is not to say I support Google's recent decisions, but then again, I had already moved off their applications (Reader and Gmail) way before the shutdowns started, mostly due to the methods used to push Chrome.
  - steveklabnik 13y ago
    They embraced standards via XMPP. They then extended them in proprietary ways, with Hangouts rather than gtalk. They then are deprecating gtalk in favor of Hangouts, and will finally extinguish it.
    - jmillikin 13y ago
      Hangouts is not an extension of XMPP, it is a replacement. Google's extensions to XMPP took place via the XEP process, and were published so other vendors could implement them.
      - zobzu 13y ago
        That's exactly the same thing. Once you own most of the implementations running "the standard" you modify it and close it so that nobody can follow your path. It does not matter if the said modifications are called "G-XMPP" or 'Hangouts'. The result and logic are the same. The rest is a useless fight on semantics.
        jmillikin 13y ago
        The Hangouts protocol is not a modified or closed version of XMPP. They have nothing in common except that they're both used to implement IM clients. SSH is not an extended version of Telnet.
        zobzu 13y ago
        And then again.. you didn't get the point. SSH and Telnet do the same thing, but nobody killed off telnet by getting everyone to use their implementation of it, then kill it and propose SSH as alternative. Thats what Hangout does. Name 5 of your friends without a google account who use internet & mobile phones. See what I mean? They were using XMPP. Everyone could talk to them using XMPP. Not anymore. Wanna talk to them? Gotta use hangout, no way around it. It does not matter if its based on the same _code_ what matter is that it offers the same functionality AND kills off the previous product by using their market share. That's the freaking concept.

dvt 13y ago

Really? Can you so harshly judge Google on abandoning a (lets face it) terrible protocol? Maybe I could get over the fact that it's so complex -- which puts an unnecessary strain on both servers and clients -- and maybe I could get over the fact that (on average) servers consume 40% more memory than their IRC counterparts. Maybe I could even get over the fact that the spec could change at any moment (the eXtensible nature of it isn't necessarily a good thing, you know). But what I couldn't possibly in a million years get over is that... it's XML (shudder). -- To the downvoters: Here's some previous discussion about why XMPP sucks: https://news.ycombinator.com/item?id=2069810 https://news.ycombinator.com/item?id=2069810 I'm currently working on a project that deals with real time communication (think IRC for the new web) and after fidgeting around with XMPP for a couple of weeks, I gave up on it completely. It's awful. I doubt many people have implemented an XMPP client (or even worse.. a server). Try it some time.

aimatt 13y ago
I understand the frustration of working with a fat protocol. What is a viable, open alternative though?
- dvt 13y ago
  IRC! :P Seriously though, there isn't a light one afaik. I ended up making my own -- I based it on IRC but wrapped it in JSON. It's stupid simple because chat should be easy.
  - dublinben 13y ago
    IRC is so lightweight, it's what NASA uses for their antarctic weather flights. http://arstechnica.com/information-technology/2013/01/antarctic-irc-how-nasas-flying-lab-stays-connected/ http://arstechnica.com/information-technology/2013/01/antarc...
    - mh- 13y ago
      antarctic satellite IRC? best i:line ever.

davorak 13y ago

> All that talk about Client Choice, Service Choice and Platform Choice has been replaced with "if the other big players don't play, why should we?". It seems like the impact of the other big players not playing is down played here. Did it not allow facebook users to start conversations with google talk users but not vice versa? Playing the cooperation card first is what google did, but in the iterated prisoners dilemma you often need to play the non-cooperative card if that is what your peers are doing. That really seemed to be the core of the issue. Now 5-25 years from now maybe google will have an entrenched culture of playing the non-cooperative card and will not reach for the cooperative card first but I do not judge this to be the case yet.

ralphm 13y ago
I believe I get to downplay that because the federation they joined helped grow their own network, and allowed them to do Google Talk for other domains. I know many companies that have moved their XMPP stuff to Google for that. Now those outside contacts are cut off, without any warning. Worse, they see their inside contacts online, can send them messages that never show up in Hangouts! Those big players are hardly affected, though. Also, Google could simply block those entities that don't fully federate (only).
- BarkMore 13y ago
  I believe I get to downplay that because the federation they joined helped grow their own network Do you have any evidence that federation helped Google grow the network in a significant way? allowed them to do Google Talk for other domains Are you referring to Google Talk integration with Google Apps For Your Domain? Outside evidence suggests that federation is not used between these domains. For example XMPP SRV records are not required and ignored if present.
threeseed 13y ago
There are a few examples though where Google has opted not to support or develop standards. For example WebM, SPDY and XMPP and not to mention their continued support for Motorola's despicable FRAND abuses.

kkowalczyk 13y ago

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.

fakeer 13y ago

1. Microsoft/Facebook (and maybe more corporates) didn't play by the rules. They don't believe in "give and take", they just do "take, take,..". Google didn't like it so walked out. Instead of showing the sportsman's spirit and instead d of carried on despite of all the follies they simply left having pissed off. Good decision. 2. Universities, organisations? The number is too small to be bothered about, esp when compared with the likes of the two above^. They would rather innovate and try to lock-in users into their own platforms rather than hoping someday Cuck might turn the benevolent saint. 3. Whatever you say but unless you are short of manpower and talent it's actually easier difficult to innovate in-house sth proprietary and not when you've to conform to a "standard" and that too when the rewards are [1]. 4. Even I don't like the move but it was a business decision and this one made a lot more sense than killing off GR. The surprising fact here is, we hardly see anyone criticizing the providers that chose not to share back. We, keep on saying "no problems with XMPP" and "even though MS and Fb were not giving back, Google should have just let them free-load after all it's a do no eveil corp". Huh.

ralphm 13y ago
At least Microsoft has XMPP federation support in Lync: http://en.wikipedia.org/wiki/Microsoft_Lync_Server#XMPP http://en.wikipedia.org/wiki/Microsoft_Lync_Server#XMPP. Otherwise, yes, Skype and Facebook should add federation support. The actual protocol isn't even that important, as long it can be implemented freely.
onedev 13y ago
I'm interested in how you think MSFT and FB just "took, took, took..."
- fakeer 13y ago
  Thank you for asking. Seems you have not been paying attention recently. Certainly not in the contxt of microsoft+facebook+gtalk+xmpp+google+talk one way, just google it; but that's my assumption. This is what I meant by "took...3 times". If it was sth else you wanted to know or were referring to then I obviously failed to grok that and you'll have to help me understand.

kmasters 13y ago

Isn't there a better question to be asked here? Federation is supposed to enable, well, federation. Google is not preventing XMPP federation in any way. Google is not "shutting down" XMPP or killing it. Why is Google the company important to the XMPP community? I scarcely see that it should matter. Open protocols are not exclusive clubs or infinite universes, anyone can opt in or out at any time, the rest of us will live. I think its great when big companies such as Google or whoever participate in open standards, but I also appreciate that they are in the business of providing the best product for their users (in their eyes) and are free to do what they want. When they do participate, we are getting a gift from them. Its not their obligation, right or even necessarily to their benefit. When they find other priorities fine, maybe someone more committed will move the project forward. And in other cases their NON-participation can be a gift as well. So whats the big deal?

Macha 13y ago
Google Talk was the largest federated XMPP server, and it provided an easy way for people using XMPP to talk to non-technical users. "I'll add you on XMPP" = blank stares, "I'll add you on Google Talk, just use your Gmail account" works, even if you yourself are not using Google Talk.

jjuliano 13y ago

The problem with XMPP is that it requires several open ports (5222, 5223, 5269, 5298, 8010) on the client, on the technical and practical standpoint the reason why XMPP is unpopular to big players because many businesses won't be bothered to open their ports, now if you are a solutions provider creating software for XMPP solutions for those companies, the most viable solution is to use BOSH to direct XMPP traffic to port 80, but there's another big problem, the only available BOSH library is a GPL BOSH library that you would license in order for you to not to ship your software along with it's source-code. Now if you can do the same thing over HTTP 1.1 stream, why bother with XMPP?

BarkMore 13y ago
* The problem with XMPP is that it requires several open ports (5222, 5223, 5269, 5298, 8010) on the client.* XMPP does not require any open ports on a client.
- jjuliano 13y ago
  On the server, I mean. source: I'm an ex-cofounder of a now very successful syncing solution startup who uses XMPP and I wrote the initial server and client code.
mh- 13y ago
I have no idea where you got the idea about binding all (any) of those listening ports on the client, but that is incorrect. anecdotally: % lsof -i4 -T s COMMAND PID USER FD TYPE DEVICE imagent 158 mh 6u IPv4 0x2969ca78b2e9b6bb 0t0 TCP mac:52812->pb-in-f125.1e100.net:5223 (ESTABLISHED) authoritatively: http://wiki.xmpp.org/web/SRV_Records#Ports http://wiki.xmpp.org/web/SRV_Records#Ports
- jjuliano 13y ago
  * On the server.
deleted 13y ago
[deleted]

rakeshpai 13y ago

I think I might have 2c to clarify the OP's stand, having worked on a mobile XMPP client before. This is with regards to his point about bandwidth and battery usage on mobile. XMPP is a connection-oriented stateful protocol. The connection setup process is very expensive: Connect, authenticate, advertise the list of supported client features, get the roster (contacts), and IIRC presence exchange, etc. Therefore, once you've established a connection, you really don't want it to break. Even just reconnecting is very expensive. However, in the mobile scenario, regular connection breakage is the norm. What most mobile based clients will then do is proxy the XMPP connection on the server-side and connect to the client over HTTP instead. This is well defined in the BoSH spec (XEP:124). BoSH was originally designed for web-based clients, but happens to meet the need of the mobile use-case. However, when it comes down to implementation, there are several optimizations that can be applied: 1. The roster exchange at the connection time is very expensive, and usually only sends data to the client that the client probably has already stored locally from a pervious session. Connection overhead can be reduced drastically if there was some way of versioning the roster and only transferring deltas. This was the OP was referring to. (Roster versioning, XEP:273). 2. Presence packets are one of the most chatty aspects of the protocol (x went offline, x is now online, etc). I've heard someone say that it constitutes about 80% of the packets on a typical connection, but this is anecdotal. In cases where the user isn't actively interacting with the client, having presence packets being sent all the time seems wasteful. One way to tackle this is to buffer up and de-duplicate the presence packets on the server, and send them in batches only when necessary. (For example, if x goes online, then offline, then online again, and then goes 'busy', the client only needs to know that x is busy.) I think this is what the OP was referring to when he mentioned the google:queue for delayed presence delivery. This alone can be a huge win for battery and bandwidth, since transferring data and processing it can be reduced drastically. Aside: Presence is so chatty, that some mobile clients simply don't handle presence at all. Take WhatsApp for example. It doesn't show whether every person in your list of contacts is online. The assumption is that every user is online by the nature of the device, and this assumption works in the common cases. In the edge cases is where you'd need to buffer up messages. This reduces chattiness drastically, making the protocol seem much more lightweight. (WhatsApp is based on XMPP, but have spun it off into their own thing.) Just thought I'd add these points to the discussion here, since there seemed to be some lack of understanding of the protocol. IMHO, the XML, as verbose as it is, isn't really the problem. The protocol itself is verbose and whether the transport uses XML or whatever else is of comparatively little consequence. This verbosity of the protocol (and not so much the format of data transfer) has its effect on battery life and bandwidth usage.

newman314 13y ago

If the issue is with mobile, why not build a MQTT <-> XMPP bridge or just support MQTT as an alternate protocol? http://en.wikipedia.org/wiki/MQ_Telemetry_Transport http://en.wikipedia.org/wiki/MQ_Telemetry_Transport