Conversation
Included request parameter “MaxLocationAge’ to give the developer option to mention the maximum aging of the location info, accepted by the application. If the developer wants only real-time or near real-time information, we as operators then can avoid validating against stale location info resulted from network reasons such as device switched-off, not in servicing area, device issues etc.
API version increased from 0.1.0 to 0.2.0
update default (0) for MaxLocationAge
Changed MaxLocationAge to MaxAge
bigludo7
left a comment
There was a problem hiding this comment.
Look good for me;
Thanks
jlurien
left a comment
There was a problem hiding this comment.
In v0.1 this parameter does not exist, so it is like client does not care about location age, and any implementation of the API regarding location age works. In practice this is as having a default value to a maximum.
To me this parameter makes sense when the client wants to request a location age that is more restrictive than certain default value, as I doubt a client would explicitly request anything worse than default (unless it is cheaper but we are not considering those aspects yet).
If we make it required, client is more conscious about the age concept but API may be more difficult to use as clients may doubt what value in minutes to ask, and they would ask for the minimum usually.
I think we have to know well what can be expected from the network in the common cases, and what can be assumed as "real-time". For example, if networks cannot not easily assure ages as low as 0 o 1 minutes, allowing clients to request it may be problematic, as clients probably tend to request the minimum if they have to provide a value mandatorily, For most use cases, low values in the order of few minutes would make no difference, but strictly some implementation may not fulfill age=0.
@bigludo7 do you have a strong preference on this optional vs mandatory decision? Maybe you can check also internally what a minimum "reasonable" age of data in your network is.
Also, in any case we should define also the expected behaviour when the requested age cannot be fulfilled.
| maximum: 200 | ||
| example: 50 | ||
| MaxAge: | ||
| description: Max location aging validity required by the application in Minute, Default =0 for realtime location |
There was a problem hiding this comment.
We were discussing in the original PR whether this new parameter should be mandatory or not. If mandatory, it makes no sense to define or document a default value.
|
Hello @jlurien
|
My concerns here about API usability and "dev friendliness": If default is 0, meaning "current location" (I prefer this term instead of real-time), and we make maxAge required, we are forcing clients to explicitly provide a maxAge. So if default is the best service, then I wonder in which cases a client would ask for anything worse on purpose. Only maybe if clients ask for "current location", get a first response of type "unable to provide", and then ask again for "last known location". Then, a better design approach would probably be to provide the maxAge indication as part of the response, instead of providing it in the request. Clients may not be familiar with typical ages in our networks to decide which threshold in minutes is enough to get the last known location if available. |
|
Sorry, but I had some pending comments, and there is still not agreement about how to add this new parameter. I will revert this commit and we can discuss further on this on tomorrow's meeting. For other PRs, please let's wait until we have at least the approval of at least 2 people. In the meantime, if you could read my latest comments and follow the discussion, it would be great. Thanks |
|
Hello @jlurien I need to be sure we have same understanding about API behavior. A very simple UC:
Agreed on this pattern ? I saw an inconsistency but not sure we can do better. |
|
Hi @bigludo7,
The concept of considering the age makes sense but we have to decide how to fit it in the API design, request or response, optional or required, default or not, any associated error if needed, etc. We are not in a hurry for this so let's try to find the best approach. |
Included request parameter “MaxAge’ to give the developer option to mention the maximum aging of the location info, accepted by the application.
If the developer wants only real-time or near real-time information, we as operators then can avoid validating against stale location info resulted from network reasons such as device switched-off, not in servicing area, device issues etc.