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

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

From: Tobie Langel <tobie@fb.com>
Date: Thu, 3 Jan 2013 20:37:24 +0000
To: Mounir Lamouri <mounir@lamouri.fr>, "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <F9981AFB970564408FEB7DFCF62D4408436F3AD5@PRN-MBX01-4.TheFacebook.com>


On 1/3/13 7:09 PM, "Mounir Lamouri" <mounir@lamouri.fr> wrote:

>On 03/01/13 17:14, Tobie Langel wrote:
>> On 1/3/13 5:58 PM, "Robert Shilston" <robert.shilston@ft.com> wrote:
>> 
>>> On 2 Jan 2013, at 16:24, Mounir Lamouri wrote:
>>>
>>>
>>> On 29/12/12 09:50, Hidetoshi Yokota wrote:
>>>
>>>From the above observation, is it possible to add a new requirement like
>>>
>>> below at this point in time?
>>>
>>>
>>>
>>> Req.X: User Agent SHOULD be able to obtain the information of the
>>>
>>> network, to which it attaches (e.g., connectivity or nominal
>>>capability)
>>>
>>> and it is RECOMMENDED to select an appropriate network when available.
>>>
>>>
>>>
>>> Related WGs: Device APIs WG, System Applications WG
>>>
>>>
>>>
>>> Please enlighten me if this kind of discussion has already been done
>>>and
>>>
>>> concluded.
>>>
>>>
>>>
>>> This has been discussed in DAP and there are privacy and fingerprinting
>>> concerns. Given DAP is focusing on the browser scope and it is too
>>>scary
>>> to provide such an API to all contents, it might be possible to have
>>> this done in SysApps but it will very likely be behind some kind of
>>> permission.
>>>
>>> Cheers,
>>> --
>>> Mounir
>>>
>>>
>>> I feel that the network information, whilst it could be made available,
>>> is sufficiently likely to be misleading as to be unwise to be used by
>>> developers.  The only way to establish the connection quality is to
>>> connect to the server you want to speak to.  We've written more about
>>>the
>>> challenges of network state information at
>>> http://labs.ft.com/2012/08/navigator-online-here-be-dragons/
>>> Rob
>> 
>> I'm sympathetic to the issue but the Network Info API is clearly the
>>wrong
>> way of looking at it, imho. I wrote more about this on the DAP mailing
>> list recently[1]. If something along these lines (and also much shorter)
>> would gather consensus, I'll happily add it to the doc.
>>
>> --tobie
>
>Robert and Tobie, I am not sure why you are commenting that Network
>Information API isn't the solution for that use case. Did any one said
>that Network Information API was the solution?

Heh. Good point.

--tobie
Received on Thursday, 3 January 2013 20:37:49 UTC

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