Re: Network Information API

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 Tuesday, 14 January 2014 07:09:18 UTC