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

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

From: Hidetoshi Yokota <yokota@kddilabs.jp>
Date: Fri, 11 Jan 2013 16:40:49 +0900
Message-ID: <50EFC201.1050106@kddilabs.jp>
To: public-coremob@w3.org
Hi Josh,

Thanks for your comment and sharing your experience. I also learned a
new proverb ;-). From your experience, it is not necessarily good for
the UA to be always greedy especially if the connection is charged,
which will lead to throttling or a bill shock.

I also don't think it is a good idea to tell the UA about the
instantaneous bandwidth, which usually changes very often. Coarser
information such as the connection type (WiFi/3G/LTE) will be more
useful (not always, as you say). Time-of-day or location (topography?)
could also be used, but we should start with simpler and fewer parameters.

I just thought we should more look into it along this line maybe in the
future or for the next version...


(2013/01/08 3:30), Josh Soref wrote:
> 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 Friday, 11 January 2013 07:41:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:48 UTC