Re: Network Information API

On 12/09/2013 08:45 AM, Frederick.Hirsch@nokia.com wrote:
> Josh
> 
> this seems aligned with recent discussions elsewhere that a low level interface is required to allow agility in use; however I appreciate Anssi's goal of simplification/abstraction.
> 
> how does this interface communicate the performance characteristics of each interface, or is that assumed to be known to the application (based on what, the names?)


I've been thinking about how to ask this question and after a while it
seems best to just ask it.  Pardon the newbie-ness here, if it comes out
that way!

This issue seems like a classical "standardization dilemma".  There's an
issue that has people clamoring for... something.  The Apple-related use
case examples in the collection clearly (to me) show a response to end
users grumping about their mobile data allowances being eaten up when
there's really not a compelling enough reason to do so (e.g. big
transfer that could wait for a "free" connection to be available). So
they've done something. On the other hand, it's also hard to argue
against the claim that the details of the proposed Network Information
API are not really set up to stand the test of time: it's providing some
ways to whack at the issues, but without a lot of precision, and in the
context of a constantly changing landscape where the parameters may
shift over time.  Wireless plans change, regulations change, network
technologies change. LTE may be approaching WiFi speeds, for example,
but gigabit WiFi is also in the planning, which would change the
equation again.

So we could do nothing (perhaps more accurately, keep considering where
work ought to be done and whether various other recommendations need to
be influenced to address parts of the problem - which externally will
look like "doing nothing" if it takes a long time) - and then every
environment will end up rolling their own solution, probably
incompatible, irritating developers and probably/possibly giving the
wrong level of control, too little or too much, to apps.  Or we could do
something, and risk it not really being a complete and stable solution,
but potentially helpful in the short term during a key period as the
"html5" ecosystem rolls out and either becomes real or fails (never!).

As I re-read that last bit it felt like I'm asking a question while
suggesting some answer is more favored but that's just clumsy wording
which I don't quite see how to improve, I really just mean to ask the
question: if the conditions aren't technically perfect to standardize,
as a W3C project, where do we stand on this kind of dilemma?

-- mats

Received on Thursday, 19 December 2013 03:18:58 UTC