Open akoshunyadi opened 5 months ago
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.
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
@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
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
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?
@chinaunicomyangfan yes, that's correct
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.
I like @eric-murray proposal. Looks clean. cc: @gmuratk
Problem description
Currently we have 3 different values for GET /connectivity
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