- From: Mats Wichmann <m.wichmann@samsung.com>
- Date: Wed, 18 Dec 2013 20:18:26 -0700
- To: public-device-apis@w3.org
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