W3C home > Mailing lists > Public > public-coremob@w3.org > January 2013

RE: New draft of Coremob-2012 published, plus what's next

From: Josh Soref <jsoref@rim.com>
Date: Mon, 7 Jan 2013 18:30:50 +0000
To: Hidetoshi Yokota <yokota@kddilabs.jp>, "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <957F1ECDA90E004B8DBDE23CFC94E3A33A5D057F@XMB103ECNC.rim.net>
Hidetoshi wrote:
> In most of
> the cases, however, you can get a faster access by WiFi than GSM/EDGE
> and your behavior will be different if you find your WiFi connection is
> free or without any data cap.


I recently had a number of experiences where none of these applied.

I moved a SIM subscription from a dead phone into a WiFi hotspot.

Then I connected a phone and a tablet-like creature to the hotspot. One of them probably blew the data cap on the SIM subscription, the result is that the service provider for the SIM throttled data connectivity on that subscription.

The phone would occasionally try to use the WiFi hotspot for connectivity. When it did, it got slower speeds, than when it used cellular. The only reason that the "WiFi" subscription didn't cost me money is that the service provider for the SIM use QoS for bandwidth overruns instead of charging me $$. I've unlocked the WiFi hotspot, so I can insert other SIMs where in fact the WiFi hotspot would cost me money when things use too much data (which would probably be much less data than the SIM I'm currently using, as the service provider is relatively generous).


> If webapp can know such information and
> behave wisely for you, it would be beneficial.

There's an expression "if wishes were horses" [1], unfortunately Wikipedia hasn't translated it into Japanese, so I have no idea if it will make sense....

The right behavior for a web app is to have modes like "be greedy" (download as much data as possible as fast and often as possible), "be gentle" (do the opposite), and let the user/agent know about and select among these modes.

There /might/ be a way to design an API where an app can register these modes and have the UA let the user manage the modes. But the right trigger and level for the API is as I'm describing, it is *NOT* by letting the app try to guess based on local network topography. If we designed an API as I'm describing, UAs and UA-extensions could experiment with topography bits and try to innovate solutions.... 

Also, just because I have a poor data connection now doesn't mean I won't have a worse one later (or none at all - I travel/fly often enough).

> I think this CG is a good
> place with knowledgeable people to find a way to make it forward.

[1] http://en.wikipedia.org/wiki/If_wishes_were_horses,_beggars_would_ride

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Monday, 7 January 2013 18:31:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:47 UTC