Group connection type by category.

[fbender]

Spun off of #4.

---

As said on Twitter, I'd group the network types by what type of network category they represent:

1. cellular, as in GSM,
2. local, as in local area network, i.e. both Ethernet and WiFi,
3. personal, as in personal area network, like Bluetooth, IrDA, USB Wireless, etc.,
4. unknown, as in "cannot be detected or is none of the types above".

This classification does not make any assumptions about connection speed or cost. It may however point to the stability (as in location) of the network and its participant: In cellular networks, participants are to be expected to move constantly (thereby hopping from cell to cell), while a LAN is (mostly) a fixed infrastructure, and participants are always within range of the one hub/router. A personal area network indicates close proximity to a low power networking device, and both participants and the networking device itself are highly mobile (i.e. are likely to move around like with BT tethering on a train). This leaves the last option to be unknown.

This classification has the following advantages:

• does not distinguish between WiFi and wired (while introducing a possible language for the prefs, i.e. "Only download in local network?"),
• does not introduce awkward API inconsistency (e.g. BT vs cellular),
• spec is forward compatible (also backwards compatible with obsolete networking stuff, bonus points for me!) with pretty much any connection type imaginable, i.e. does not require to add new enum types for entirely new ways to network,
• does not discriminate by connection speed, technology/protocol, or stability (as in signal) thereby sidestepping the footgun (at least theoretically),
• covers more edge cases (see printer example below),
• allows for ad-hoc networks / WiFi Direct (as commonly used in tethering[1]) to be classified as a personal area network.

The last point is essential. The hardware can tell whether the (WiFi) networking device is in ad-hoc mode (and I think the same is true for WiFi Direct) thus this information can be (and is) exposed via API which the user agent can hook into to determine the correct connection type. Note that the personal type may kick in when you have no Internet connection at all (e.g. isolated laptop-to-laptop network), and that is OK and expected (this allows covering edge cases for apps, e.g. the printer app acts differently when you're connected to your printer via WiFi Direct).

Now, there is value in knowing what "protocol" the connection is using, because surfing via GPRS is vastly different than surfing via 3G or LTE (or even EDGE), and Ethernet is different to WiFi or Bluetooth – the valuable quantities being (max.) bandwith and latency (I'm wondering why latency seldomly was an issue for these APIs) – but let's cover that in a different bug.

[1] There are exceptions, of course: I have a battery-powered WiFi router with a cellular modem (let's call it a MiFi) which quacks like a stationary router – though I specifically bought it to have high-bandwith low-cost internet when I'm abroad, i.e. I buy a local prepaid SIM to use with the MiFi. Similar situations are encountered in rural regions where the only way to have a satisfactory internet connection in homes (i.e. stationary) is to use 3G or LTE routers. In these cases, the network participant expects its connection to act like a stable, high-quality, and (for all intents and purposes) low-cost connection like DSL et al. I.e., this case is covered by the local type.

PS: There is one more connection type I'd like to mention: landline AKA modem AKA gosh-we-are-not-in-the-90s-anymore – unfortunately, this type is not uncommon even in developed countries, and I'd like to see it covered by the spec. This may fall under the cellular type (as it is comparable to GPRS or EDGE) or be its own type (thereby raising awareness for this issue among developers) though I have no idea what color the bikeshed should have … technically, DSL is also landline so that's probably not a good name, modem is not sufficient as well. Or just treat it as unknown and deal with it another time.

-- also see answers to original comment

---

Clarification about the term "cellular" vs. "mobile":

In technical terms, a cellular network is about "cells" where each cell is a logically separated area and users are an entity that moves between cells when they change their location. Huge WiFi networks with multiple APs basically extend the range of one network, the topology is like a (wired) LAN network with a flat or tree structure – it's a centralized structure whereas cellular behaves more like a WAN with independent nodes.

"Mobile" in itself doesn't say more than "not a fixed thing" and may not denote the right meaning. It's not interchangeable with "cellular".

cellular is a technology while "local" and "personal" are user-centric

They are a classification of range and stationarity (assuming I use the right term here), not user-centric (in this context). local and personal may also denote a technical classification (as in LAN & PAN), IMHO. I agree that cellular is a bit inconsistent here, though, but I think this is our only option, unfortunately.

If there is a "true" cellular mode available for 801.11 in the future (e.g. for municipal wireless networks, WiMAX?), it should probably fall under the cellular category.

(Disclaimer: I'm not familiar with the technical details but this is how it "feels" like. The bikeshedding is my personal opinion but I feel strongly for the cellular vs local vs personal distinction.)

---

FTR, here's some discussion on Twitter: https://twitter.com/marcosc/status/440107446766272513

Also note issue #7 which aims to introduce an API for querying the exact link type covering edge cases.

/cc @slightlyoff, @marcoscaceres

[marcoscaceres]

Closing, as this didn't happen unfortunately.