W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2014

Re: Network Information API

From: Francesco Iovine <f.iovine@gmail.com>
Date: Wed, 15 Jan 2014 01:05:26 +0100
Message-ID: <CALE=BGTAbUvYG=2AFQ7jWh_XLdyCBRY9_3_8crqpmhfX-yzU2Q@mail.gmail.com>
To: Fernando Jiménez Moreno <ferjmoreno@gmail.com>
Cc: Marcos Caceres <w3c@marcosc.com>, Mats Wichmann <m.wichmann@samsung.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Fernando,

I have read your proposal, I think it's very well written and
comprehensive, very useful to me.

What I want to point out here is that, if I didn't miss something, Marcos
proposed an alternative API design based on the new NetInfo interface:

http://lists.w3.org/Archives/Public/public-device-apis/2014Jan/0013.html

What I have understood is that the new spec proposed by Marcos provides the
following objects/properties:

navigator.netInfo
navigator.netInfo.connection
navigator.netInfo.connection.type  // "wifi", "cellular", "disabled"
navigator.netInfo.onconnectionchange

I like this new API design mainly because in this way the API can be easily
extended by adding properties to the NetInfo object.

Also, the new NetInfo object might be useful to distinguish User-Agents
implementing the latest spec from User-Agents implementing the
specification v1 (2011). Something like:

if (navigator.netInfo) { /* Upcoming W3C spec */
}
else if (navigator.connection) { /* W3C Working Draft 7 June 2011 */
}

What do you think about?

Best ;)

Francesco <https://developer.mozilla.org/en-US/profiles/franciov>


On 13 January 2014 19:01, Fernando Jiménez Moreno <ferjmoreno@gmail.com>wrote:

> Hi!
>
> This is my first email to the public list, so allow me to do a very quick
> introduction of myself. I am a software engineer at Telefónica Digital
> working in Firefox OS since the very beginning of the project in different
> areas like the radio interface layer, payments, web apps, identity and
> other system components that are more or less related with the topics
> discussed in this mailing list. I volunteered to take a look at the Network
> Information API a few weeks ago and I've been working on it with Marcos and
> Gene since then hoping to be able to contribute to it the best that I can.
>
> And now, back in topic, I just wanted to mention that I created [1] a few
> days ago to follow up the work done in [2] with a more concrete proposal
> for this API which is pretty much the same proposal that Marcos drafted in
> his previous email with some small additions, examples and a quick
> rationale behind the changes.
>
> Cheers,
>
> / Fernando
>
> [1] https://github.com/ferjm/w3c-netinfo-v3-proposal
> [2] https://github.com/w3c-webmob/netinfo
>
> On 09/01/2014, at 06:00, Marcos Caceres <w3c@marcosc.com> wrote:
>
> >
> >
> > On Thursday, December 19, 2013 at 1:18 PM, Mats Wichmann wrote:
> >
> >> 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?
> >
> > I guess where we are now. Trying to figure out if we do anything at all
> by throwing use cases, data, and citations at each other :)
> >
> > I think we’ve gotten to a good place through this process, though. I’d
> be happy to draft up and alternative API design based on the discussions
> we’ve had.
> >
> > Something like:
> >
> > interface NetInfo : EventTarget{
> >   readonly attribute ConnectionType connection;
> >   readonly attribute onconnectionchange;
> > }
> >
> > //We can add new types as needed in the future - disabled can be a stand
> in for “airplane” mode or similar user-controlled network disconnect.
> >
> > enum ConnectionType{ “wifi”, “cellular”, “disabled”}
> >
> >
> >
> > partial interface Navigator{
> >    readonly attribute NetInfo netInfo;
> > }
> >
> >
> > Then it’s composable with other APIs  - like battery status, to address
> Tobie’s use cases of being able to make smarter decisions about when to
> sync (FWIW, I think having better primitives that devs can work with would
> be better than deferring all this to the UA - at least initially till we
> see clear usage patterns):
> >
> > window.onload = (e) => {
> > var battery = navigator.battery,
> >      netInfo = navigator.netInfo;
> > if(!battery.charging  && netInfo.connection ===
> prefs.preferredSyncConnectionType){
> >   //do synchronization
> > }
> > }
> >
> >
> > //Stop transferring data when discharging
> > battery.addEventListener(“chargingchange”, (e) => {
> >   if(battery.charging && app.isSyncing){
> >    app.stopSync();
> >   }
> > });
> >
> >
> > netInfo.addEventListener(“connectionchange”, (e) =>{
> >   if(NetInfo.connection === “cellular” && fetchQueue.state ===
> “fetching"){
> >
>  fetchQueue.pauseAllDownloads().then(confirmProceedWithUser).then(fetchQueue.resume);
> >  }
> > } );
> >
> >
> >
> >
> >
>
>
>
>
Received on Wednesday, 15 January 2014 00:05:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:03 UTC