souldn't be impossible to do. i use opera mini on android, ios and symbian and it's remote compression reduces data so that i can browse the web all day and get nowhere near my 50mb daily limit.
it would be possible for google to create a service/api that does something similar for other apps.
It appears that this failure was not due to bandwidth itself, but to a burst in the sheer number of app-level phone-homes. NTT employs pretty sophisticated traffic classification and routing and my guess is that the actual number of "control channel" connections burst to a level that the hardware they'd allotted to handle these sorts of connections couldn't deal with, resulting in some cascading failures. And for some reason, they don't want to (or can't) go all elastic for this type of traffic.
It also sounds like what they want Google to do is to have app developers route through so that connections pool into a single thread? They don't mention c2dm at all, but seems like forcing c2dm would help (though it would leave Android =<2.1 users in the cold)?
Opera Mini is extremely aggressive in its "optimization", which is lossy, quite specific to the web, creates a sub-par user experience, and is utterly inapplicable to the kind of data NTT is complaining about.
At best, you could wrap the protocols in zlib, but if that actually helped, I'd say NTT's network is already hanging by a thread (and indeed it appears to be). Streaming a five minute video can account for hours, if not days, of polling by email, social media, and other 24/7 background-running clients
The majority of carriers already compress data on-the-fly, to the point where it wouldn't be unknown for application developers to resort to tricks such as base-64 encoding and zipping images up to avoid automatic compression.
There are pros and cons to this approach: some people (me!) appreciate the compression carriers provide, because it saves my bandwidth allowance. But if you had unlimited bandwidth and a fast 3G connection, perhaps you would feel differently.
I have no problem in general with the lossless compression of text or the transparent re-compression of images on websites, especially since most people are utterly clueless about how much bandwidth they waste on poorly-packed PNGs, obscenely-high-"quality" JPEGs, and even posting bizarrely high-resolution images and depending on img tag parameters to display it reasonably.
Opera Mini is far more invasive, however. What actually gets transmitted to your device is not even HTML, and the JavaScript support is severely limited. It's not just "compression" in the sense we usually understand it, it significantly alters the nature of the data being transmitted.
Comments
souldn't be impossible to do. i use opera mini on android, ios and symbian and it's remote compression reduces data so that i can browse the web all day and get nowhere near my 50mb daily limit.
it would be possible for google to create a service/api that does something similar for other apps.
It appears that this failure was not due to bandwidth itself, but to a burst in the sheer number of app-level phone-homes. NTT employs pretty sophisticated traffic classification and routing and my guess is that the actual number of "control channel" connections burst to a level that the hardware they'd allotted to handle these sorts of connections couldn't deal with, resulting in some cascading failures. And for some reason, they don't want to (or can't) go all elastic for this type of traffic.
Here's some background:
http://itpro.nikkeibp.co.jp/article/NEWS/20120127/379582/
It's in Japanese, but the Google Translation gives way more info than the TNW and Reuters articles: http://translate.google.com/translate?sl=ja&tl=en&js...)
It also sounds like what they want Google to do is to have app developers route through so that connections pool into a single thread? They don't mention c2dm at all, but seems like forcing c2dm would help (though it would leave Android =<2.1 users in the cold)?
Opera Mini is extremely aggressive in its "optimization", which is lossy, quite specific to the web, creates a sub-par user experience, and is utterly inapplicable to the kind of data NTT is complaining about.
At best, you could wrap the protocols in zlib, but if that actually helped, I'd say NTT's network is already hanging by a thread (and indeed it appears to be). Streaming a five minute video can account for hours, if not days, of polling by email, social media, and other 24/7 background-running clients
The majority of carriers already compress data on-the-fly, to the point where it wouldn't be unknown for application developers to resort to tricks such as base-64 encoding and zipping images up to avoid automatic compression.
There are pros and cons to this approach: some people (me!) appreciate the compression carriers provide, because it saves my bandwidth allowance. But if you had unlimited bandwidth and a fast 3G connection, perhaps you would feel differently.
I have no problem in general with the lossless compression of text or the transparent re-compression of images on websites, especially since most people are utterly clueless about how much bandwidth they waste on poorly-packed PNGs, obscenely-high-"quality" JPEGs, and even posting bizarrely high-resolution images and depending on img tag parameters to display it reasonably.
Opera Mini is far more invasive, however. What actually gets transmitted to your device is not even HTML, and the JavaScript support is severely limited. It's not just "compression" in the sense we usually understand it, it significantly alters the nature of the data being transmitted.