922584 - B2G RIL: provide WebAPI to setup network connections and expose connection state

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The setting 'ril.radio.disabled' is overused since it's not for indicating user preference of enabling a data call but also for indicating the data connection state. 
The meaning of the setting is ambiguous and error-prone. It would be great to provide an WebAPI for function call, and leave the setting for user preference only.

Besides, considering multisim scenario, having this kind of API would help clearly specify through which sim card we want to setup a data connection.

Comment 1

[Ken Chang[:kenkai]]

Should we create a component to handle all network connections(data call, wifi, and so on)?

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Ken Chang from comment #1)
> Should we create a component to handle all network connections(data call,
> wifi, and so on)?

In addition to the existing RIL and Wifi components? If that's the case the need isn't so obvious to me right now. And it might cause more confusion in choosing a proper one.

Comment 3

[Ken Chang[:kenkai]]

(In reply to Hsin-Yi Tsai (OOO 10/2 ~ 10/13)  [:hsinyi] from comment #2)
Just like what Edgar had proposed before, it seems to be better to have a "ConnectionManager" to handle this.

Comment 4

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Ken Chang from comment #3)
> (In reply to Hsin-Yi Tsai (OOO 10/2 ~ 10/13)  [:hsinyi] from comment #2)
> Just like what Edgar had proposed before, it seems to be better to have a
> "ConnectionManager" to handle this.

Aha, sorry I misunderstood your comment. I was thinking about 'bugzilla component = =

Yup, it would be good to have a central component to manage all kinds of data connection just as Edgar proposed in [1], but [1] doesn't touch webAPI for enabling/disabling data connection. And this bug is filed for that. However, having a central connection manager seems work. 

Cc wifi developers to join the discussion.

[1] https://docs.google.com/drawings/d/1wldBv82IsGwls-a3yAFDB-Jj1HeOtUnDuJRg7JfzRQU/edit

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai (OOO 10/2 ~ 10/13)  [:hsinyi] from comment #4)
> (In reply to Ken Chang from comment #3)
> > (In reply to Hsin-Yi Tsai (OOO 10/2 ~ 10/13)  [:hsinyi] from comment #2)
> > Just like what Edgar had proposed before, it seems to be better to have a
> > "ConnectionManager" to handle this.
> 
> Aha, sorry I misunderstood your comment. I was thinking about 'bugzilla
> component = =
> 
> Yup, it would be good to have a central component to manage all kinds of
> data connection just as Edgar proposed in [1], but [1] doesn't touch webAPI
> for enabling/disabling data connection. 

In [1], the network manager listens to settings value such ril.data.enabled to control data connection. In the long long term (our final goal), we'd like to have a network manager WebAPI and have a function for data enabling.

In the short term (for multisim), seems we need to figure out an acceptable solution.

> And this bug is filed for that.
> However, having a central connection manager seems work. 
> 
> Cc wifi developers to join the discussion.
> 
> [1]
> https://docs.google.com/drawings/d/1wldBv82IsGwls-a3yAFDB-
> Jj1HeOtUnDuJRg7JfzRQU/edit

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #5)
> (In reply to Hsin-Yi Tsai (OOO 10/2 ~ 10/13)  [:hsinyi] from comment #4)
> > (In reply to Ken Chang from comment #3)
> > > (In reply to Hsin-Yi Tsai (OOO 10/2 ~ 10/13)  [:hsinyi] from comment #2)
> > > Just like what Edgar had proposed before, it seems to be better to have a
> > > "ConnectionManager" to handle this.
> > 
> > Aha, sorry I misunderstood your comment. I was thinking about 'bugzilla
> > component = =
> > 
> > Yup, it would be good to have a central component to manage all kinds of
> > data connection just as Edgar proposed in [1], but [1] doesn't touch webAPI
> > for enabling/disabling data connection. 
> 
> In [1], the network manager listens to settings value such ril.data.enabled
> to control data connection. In the long long term (our final goal), we'd
> like to have a network manager WebAPI and have a function for data enabling.
> 
> In the short term (for multisim), seems we need to figure out an acceptable
> solution.
> 

Per discussion with Ken, we think in multisim scenario (v1.3) no settings or API changes are needed.
RIL still listens to 'ril.data.enabled' to control data connection. If user is willing to enable a data call, then RIL code should use the user-specified default service to setup up the data call.

In the meanwhile, we could keep discussing a long-term solution, such as creating a new WebAPI, ConnectionManager maybe, to manages all kinds of connections.

How does this sound?

> > And this bug is filed for that.
> > However, having a central connection manager seems work. 
> > 
> > Cc wifi developers to join the discussion.
> > 
> > [1]
> > https://docs.google.com/drawings/d/1wldBv82IsGwls-a3yAFDB-
> > Jj1HeOtUnDuJRg7JfzRQU/edit

Comment 7

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Reference bug for network manager enhancement: bug 904514

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Another use case is:
In DSDS, user needs to change the primary sim setting if MMS is coming on the non-primary sim and user wants to download the MMS.

The problem gaia faces is that right now we only have 'ril.data.enabled' to represent the state of data connection of default type. Gaia has no idea about whether MMS connection is ready after switching the setting. Exposing connection state and firing events makes gaia's life easier.

Comment 9

[Hsin-Yi Tsai (she/her) [:hsinyi]]

bug 961938 comment#2 clearly indicates a request of getting data connection state.
1) Gaia needs to know whether the serviceId for the data connection changes (on DSDS)
2) Gaia needs to know the state of a specific type of data connection. Or Gaia needs to know whether a type of data connection is connected or not.

Very initial draft:
interface ConnectionManager {
  DOMString[] getConnectedDataTypes();
  event onservicechange; // when data connection is switched to another service/SIM
  event ontypechange; // when connection type is changed: default, mms, supl ...
}

Issues:
1) The scope of this API: including data connections only? Or wifi connections as well?
2) DSDA Multisim support

Comment 10

[Ken Chang[:kenkai]]

Put this bug into backlog.

Comment 11

[John Shih]

Per offline-discussion, we would like to provide an generic "Connection API", which will take charge of all kinds of connections including WiFi, Ethernet, Mobile, Hotspot... etc.

We will start the discussion thread of API here.

Comment 12

[Ken Chang[:kenkai]]

Set a target milestone for this bug.

Comment 13

[Jessica Jong [:jessica] (inactive)]

Sorry to jump in, is the scope of this bug same as Bug 928861? It seems that Bug 928861 is also trying to add a generic api in NetworkManager for acquiring a certain connection.
IMHO, there are two parts to be handled. One is to add an internal api (something like connect/disconnect) in NetworkInterface for NetworkManager to use, and the other part is to provide a generic api in NetworkManager so that users can use this api to acquire any of the network connections, e.g. mobile, wifi, ethernet, etc. Is this correct?

Comment 14

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #13)
> Sorry to jump in, is the scope of this bug same as Bug 928861? 

Not exactly. As you mentioned, bug 928861 is for internal API, and this is for WebAPI. But of course, to achieve this, bug 928861 might be needed as well. I didn't notice that one before, so I just set the dependency with bug 904514.

> It seems that
> Bug 928861 is also trying to add a generic api in NetworkManager for
> acquiring a certain connection.
> IMHO, there are two parts to be handled. One is to add an internal api
> (something like connect/disconnect) in NetworkInterface for NetworkManager
> to use, and the other part is to provide a generic api in NetworkManager so
> that users can use this api to acquire any of the network connections, e.g.
> mobile, wifi, ethernet, etc. Is this correct?

Correct!

Comment 15

[John Shih]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #13)
> Sorry to jump in, is the scope of this bug same as Bug 928861? It seems that
> Bug 928861 is also trying to add a generic api in NetworkManager for
> acquiring a certain connection.
> IMHO, there are two parts to be handled. One is to add an internal api
> (something like connect/disconnect) in NetworkInterface for NetworkManager
> to use, 

I think that's what Bug 928861 intended to do. That is, provide more generic api for internal use.

> and the other part is to provide a generic api in NetworkManager so
> that users can use this api to acquire any of the network connections, e.g.
> mobile, wifi, ethernet, etc. Is this correct?

And this part is what we're going to do in this bug. As you mentioned, there would be a new API (probably named mozNetworkManager) that allows gaia to control different connections through it.

Comment 16

[Jessica Jong [:jessica] (inactive)]

Oooh, I understand now. Thanks Hsinyi and John for the clarification!

Comment 17

[John Shih]

Attachment: draft IDL proposal

This is an draft proposal for NetworkManager API.
The basic idea is to control different types of network (wifi, ethernet, cellualr) through NetworkManager.

For example,
Ethernet can be obtained by using
var ethernet = navigator.mozNetworkManager.getNetwork("ethernet");
And then developers can do the operations (enable/connect) on |ethernet| object.

Comment 18

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 8421572 [details] [diff] [review]
draft IDL proposal

Review of attachment 8421572 [details] [diff] [review]:
-----------------------------------------------------------------

Apparently we have more to discuss with.  We need some way to create/add a new connection definition as well as to remove.  I'd like to avoid that "active network" concept because it doesn't scale.  We also have problem defining connections with no specific underlying device such as VPN connections.  Maybe we should move getConnections() to NetworkManager as well.  Then we may add Connection::connect(optional Device).  We might also have to separate connection definitions from active connections, so that we may allow editing static connection preferences for ethernet interfaces and reactivate it.  Something like NetworkManager::addConnection(ConnectionSettings), where ConnectionSettings is yet another undefined interface.  FreeDesktop NetworkManager uses terms Connection & ActiveConnection for same purpose.

::: dom/webidl/MozNetworkManager.webidl
@@ +20,5 @@
> +}
> +
> +[JSImplementation="@mozilla.org/moznetwork;1",
> + Func="Navigator::HasNetworkManagerSupport"]
> +interface MozNetwork : EventTarget {

We have already a nsIMozNavigatorNetwork in http://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIMozNavigatorNetwork.idl . Will it be ambiguous here? How about NetworkDevice?  So in the future we can have yet another derived interface WifiNetworkDevice, which features two additional APIs -- getAccessPoints() and scan().

@@ +50,5 @@
> +   */
> +  readonly attribute NetworkType type;
> +
> +  readonly attribute boolean enabled;
> +  readonly attribute boolean connected;

"connected" duplicates activeConnection in meaning.

@@ +71,5 @@
> +  readonly attribute MozNetwork? activeNetwork;
> +
> +
> +  /* Return the network based on the given type.
> +  Promise getNetwork(NetworkType type);

I'd really hope we can build in multiple devices concept for a new API from now on.  AFAIK, TV is going to have multiple ethernet interfaces, isn't it?  So probably this has to return an array, and that parameter should be optional, which means all when omitted.

@@ +76,5 @@
> +
> +  /*
> +   * Retrun the list of currently available networks.
> +   */
> +  sequence<NetworkType> getListOfNetworks();

So I think we don't need this because getNetwork() returns an empty array when there is no device available of specified NetworkType.

Comment 19

[Ethan Tseng [:ethan]]

Attachment: Class Diagram of Draft MozNetworkManager WebIDL.svg

A class diagram according to the draft MozNetworkManager WebIDL.
Hopefully will be used to facilitate discussion by visualization.

Comment 20

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8421572 [details] [diff] [review]
draft IDL proposal

Review of attachment 8421572 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/webidl/MozNetworkManager.webidl
@@ +31,5 @@
> +
> +  /*
> +   * Make network esbtablish a connection.
> +   */
> +  Promise connect(optional MozConnection connection);

Do we allow the API to set ip mode to dhcp or static ? Or it is defined by network device itself, ie, wifiManager.

@@ +32,5 @@
> +  /*
> +   * Make network esbtablish a connection.
> +   */
> +  Promise connect(optional MozConnection connection);
> +  Promise disconnect();

What does connect/disconnect APIs mean ? Don't we need to specify a SSID when connecting to the AP ? 
In that case, do we need to have a getNetworks API to obtain available SSIDs ?

Comment 21

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Comment on attachment 8421572 [details] [diff] [review]
draft IDL proposal

Review of attachment 8421572 [details] [diff] [review]:
-----------------------------------------------------------------

Basically, I think we need to review the use cases before diving into the .webidl design. I don't have a very clear picture of the whole scope, especially each type of network could have very different behaviour and request.

::: dom/webidl/MozNetworkManager.webidl
@@ +37,5 @@
> +
> +  /*
> +   * Return list of available connections for the network.
> +   */
> +  sequence<MozConnection> getListOfConnections();

When and how MozConnection is determined? And is the determination dependent on NetworkType? Please elaborate more!

@@ +47,5 @@
> +
> +  /*
> +   * Represent the type of network.
> +   */
> +  readonly attribute NetworkType type;

We also need connectionType, e.g. default, mms, supl....

@@ +67,5 @@
> +
> +  /*
> +   * Active network. Null if networking is disabled.
> +   */
> +  readonly attribute MozNetwork? activeNetwork;

What does 'active' really mean, connected? enabled? And Only one active network is available at a time?
No matter 'connected' or 'enabled' it seems it's very likely to have more than one.

Comment 22

[Jeff Chuang]

Dear all,

I would like to know more details about B2G network sub-system. Do you know where or which bug can I find the architecture, control flow of FxOS network sub-system? I would like to study the materials about both the current design and the new one.
Thank you

Comment 23

[BMO Automation]

Firefox OS is not being worked on