Extend the possible connectivity values

[akoshunyadi]

Problem description

Currently we have 3 different values for GET /connectivity
- CONNECTED_DATA
- CONNECTED_SMS
- NOT_CONNECTED

DATA was meant to be returned when data connectivity is given, regardless of the SMS connectivity. But in some cases a finer differentiation is needed.

Possible evolution
CONNECTIVITY_DATA should be returned if only data connectivity is given but no SMS.
either a new value CONNECTIVITY_DATA_SMS should be introduced
or more than 1 value should be returned

The same applies for the connectivity events.

Alternative solution

Additional context

[sachinvodafone]

Currently, we have two possible connectivity statuses: "SMS" and "Data". If we're confident that these are the only two possible statuses, then "CONNECTIVITY_DATA_SMS" seems appropriate. However, I lean towards passing multiple statuses in the same response, such as "CONNECTED_DATA" and "CONNECTED_SMS", which would accommodate any future requirements if a third status is introduced.

[maxl2287]

Additionally

What about also "UNKNOWN" as a possible value?
When the service tries to call the network to get some information, but the network cannot deliver either information about DATA nor SMS.
Then you cannot respond with "NOT_CONNECTED".

Wdyt?

I have added an issue about this topic #148

[murthygorty]

@akoshunyadi , personally I recommend that we go with an array as response.

1. This will enable the caller to look at the capabiltiies and act on what they want. (a single logic for connected_SMS)
2. this is also extensible for other types in the future connected_IMS_DATA for example..
   @gmuratk @NoelWirzius

[murthygorty]

further thoughts - thanks @gmuratk for the discussion.
we can return an object as the response.
"CONNECTIVITY_DATA": enum [YES, NO, UNKNOWN]
"CONNECTIVITY_SMS": enum [YES, NO, UNKNOWN]

-- same structure will help in returning different connectiviity-types in the future IMS_DATA for example.
-- this has facility to return UNKNOWN, let's say CSP knows that SMS is yes, but didn't proper info for DATA. Like @maxl2287
-- allows a developer to simply look at the status and type they care about for their use case.

cc: @akoshunyadi , @NoelWirzius , @gmuratk @sachinvodafone

[chinaunicomyangfan]

May I ask how to understand these two enumeration values？
CONNECTED_DATA means that the device can access the internet through data traffic.
CONNECTED_SMS means that the device can make phone calls or send text messages.
Is this understanding correct？

[akoshunyadi]

@chinaunicomyangfan yes, that's correct

[eric-murray]

I would propose that device-reachability-status follows the pattern used by device-roaming-status by adopting a "primary" response field, which is the status itself (true / false) and then additional field(s) giving more information when the status is true.

So we could have the following response when the device is not reachable:

{
  "reachable": false
}

or the following (example) when the device is reachable:

{
  "reachable": true,
  "connectivity": [ DATA, SMS ]
}

It would then be straightforward to extend connectivity with additional options as these are agreed. This would have no effect on API consumers who are only interested in whether or not a device is reachable, as they could continue to check only the primary status.

[murthygorty]

I like @eric-murray proposal. Looks clean.
cc: @gmuratk

[QaunainM]

Hi all, btw we've got some feedback from prospects and they would prefer for the API response to be the way you have all suggested which is an array that shows all the connected types opposed to just one value which could miss out all the connection types.