introduce NetworkLink interface

[fbender]

I created a proposal that is intended to extend to edge cases my proposal in issue #4 does not cover – though it does not replace it. It may look like a step back but it's about enabling developers while keeping sane defaults / recommendations.

See: https://gist.github.com/fbender/9322762

[jkarlin]

+1 to exposing more link information. Let's either expose what we can about the links or the minimum (celullar vs non-cellular). The in-between (wifi/ethernet/cellular/bluetooth/other) state we're in now makes little sense to me.

[marcoscaceres]

@jkarlin, as we were not getting positive signals from other Googlers we more or less stopped all work on this. On the Moz side, we are happy to restart the effort to standardize (though it might need to wait till next quarter).

About the "in-between", the idea was to provide an API that allowed one to build the applications shown in the use cases document. That's not to say we can't do better, but we thought that we could at least expose enough for developers to build similar experiences.

[jkarlin]

@marcoscaceres @slightlyoff I have support from several Googlers to implement NetInfo v3 (behind a flag for now). Adding more detail (2g/3g/4g etc.) would be useful for:

1. User-preference to load media when on 4g but not 3g
2. For getting a better understanding of user experience based on the radio

[marcoscaceres]

@jkarlin, that's good to hear. We (Moz) have also implemented the spec in FxOS Bug 960426 but we would like to expose this to the Web at some point.

To be clear, when you say the v3 spec, do you also mean this spec: http://w3c.github.io/netinfo/ or the one that Google was proposing?

About 2g/3g/4g: we are concerned about people creating poor interfaces/experiences by distinguishing between, and making bad assumptions about, 3G, 4G, etc. connections. See 1, 2, and in particular 3 (Economist)... none of these really make sense on devices like the Nexus 7, where there is no cellular connection at all. That really only left us with distinction between sync over WiFi and "other" (be it cellular, ethernet, or bluetooth).

[jkarlin]

Yes, v3 referring to http://w3c.github.io/netinfo/

Any way we carve this bad assumptions (such as wifi connections being reliable or unmetered) are going to be made. I think there is genuine use for exposing more information about the radio in a separate attribute. Also, being in a separate attribute, developers may be less likely to use it unless they need it.

[jkarlin]

That said, if there is strong opposition to the idea I'm willing to implement as-is as it's better than not making progress here. And we could always add the extra attribute later.

[marcoscaceres]

Yeah, let's start small and add something later once we get a better understanding of how people will use this.

[igrigorik]

@marcoscaceres how do we get this feedback when both implementations are behind flags?

FWIW, NetInfo plugin for Cordova is one of their most popular plugins and exposes more detailed information: https://github.com/apache/cordova-plugin-network-information/blob/master/doc/index.md - 2G, 3G, 4G.

[marcoscaceres]

@igrigorik although it's maybe not ideal, the feedback we would be getting would be from the developers working on privileged FxOS applications making use of the API.

I've pinged the Cordova folks a bunch of times about the Netinfo API and what devs are using it for (see list archive). Unfortunately they don't have any data to share and don't track this information. It's unclear why it's so popular and what developers are using it for there. I would not be comfortable making any assumptions from the Cordova usage stats until we can actually interpret them.

[igrigorik]

@marcoscaceres my concern is that "cellular" is basically navigator.onLine in its current state... For cases (i.e. on mobile handsets) where this API actually becomes interesting (and useful, in my opinion) we expose the least amount of useful information. My personal preference would be to expose as much information as possible - e.g. https://gist.github.com/slightlyoff/4755944.

If you're building a native app, you have access to this data. I don't see why we're hiding:

• http://developer.android.com/reference/android/telephony/TelephonyManager.html (see subtype)
• http://stackoverflow.com/questions/2802472/detect-network-connection-type-on-android/8548926#8548926

[marcoscaceres]

For cases (i.e. on mobile handsets) where this API actually becomes interesting (and useful, in my opinion) we expose the least amount of useful information.

Generally, I agree that approach is preferable (hence me also being a large supporter of what @fbender was proposing also).

We probably have a different set of use cases in mind here. The API, as currently is, for allowing the creation of apps like the ones seen here (not all - as some are bad uses of the API, but ones like Audible show what I consider "good" uses of the API): http://w3c-webmob.github.io/netinfo-usecases/

Also note that the stackoverflow example does what we would consider "bad" and would lead to abuse cases (isConnectionFast()).

[igrigorik]

For cases (i.e. on mobile handsets) where this API actually becomes interesting (and useful, in my opinion) we expose the least amount of useful information.

Generally, I agree that approach is preferable (hence me also being a large supporter of what @fbender was proposing also).

In which case, what's the underlying issue we're actually discussing? Is it the following...

About 2g/3g/4g: we are concerned about people creating poor interfaces/experiences by distinguishing between, and making bad assumptions about, 3G, 4G, etc. connections. See 1, 2, and in particular 3 (Economist)... none of these really make sense on devices like the Nexus 7, where there is no cellular connection at all. That really only left us with distinction between sync over WiFi and "other" (be it cellular, ethernet, or bluetooth).

There is always potential for someone shooting themselves in the foot. There are plenty of examples of various JS libraries that issue a "quick download" to gauge connection speed to determine how they should behave - e.g. pick asset type to download... insert all the reasons why this can go wrong here. This should not stop us from providing useful information to developers that know what they're doing.

Preventing the good developers from building great experiences based on this data is a much worse outcome than trying to "prevent" bad developers from doing bad things -- you can't stop them anyway, they do this already.

[marcoscaceres]

Preventing the good developers from building great experiences based on this data is a much worse outcome than trying to "prevent" bad developers from doing bad things -- you can't stop them anyway, they do this already.

Believe me, you are preaching to the converted. But I'd still like to know is what is missing from the current set that would limit good developers and in what way (which is what I hope we will find out from Mozilla folks using the API in practice in Firefox OS). We can, of course, expose all the things related to the network connection - but I guess what I'm initially trying to find is the middle ground that allows devs to build the experiences they want without over-burdening implementers exposing things that might never get used. I know that this risks being short sighted on my part (from a lack of imagination from what people might be able to do with "3GPP-LTE" or whatever) - but it seems like a good place to start.

Consider that we can also extend the API in the future if developers find it too limiting. Like, V1 only exposing the type, and V2 providing the additional details about the connection.

[igrigorik]

Consider that we can also extend the API in the future if developers find it too limiting. Like, V1 only exposing the type, and V2 providing the additional details about the connection.

Yes, I'm just not convinced that current v1 is sufficient. An in between would be to take it one level deeper: 2G/3G/4G and leave the rest of v1 as is. To me that would be a big step forward, and if that's enough, then we can consider exposing detailed connection info in next version.

[marcoscaceres]

Closing, as there doesn't seem to be further action needed on this bug.