Another point that we should also probably discuss here is at subscription time.
Suppose we get a subscription for an area not covered or below a given percentage, or, for an area too small to be valid (N% will never be above x with current network ).
In these case the consumer will never be able to receive notification.
I tend to think that we must be pro-active on this and refuse the subscription with a explicit message. So we must add this capability in our API.
Probably this extra layer of checking could challenge our capability to answer synchronously to the call so also I'm wondering if we should not add capability to answer asynchronously to geofencing request.
During team meeting June 4th, 2024 we discussed following proposal:
Add a 422 error when the API provider is able to answer 'on the fly' that the area is not 'manage-able'. This one to cover sync scenario
Add a terminationReason to indicate that the the area is not 'manage-able'. The API provider sends a termination event to inform consumer that it will not be able to manage the area. This one to cover async scenario when the API provider assesses 'offline' that the area cannot be covered.
Another point that we should also probably discuss here is at subscription time.
Suppose we get a subscription for an area not covered or below a given percentage, or, for an area too small to be valid (N% will never be above x with current network ). In these case the consumer will never be able to receive notification.
I tend to think that we must be pro-active on this and refuse the subscription with a explicit message. So we must add this capability in our API.
Probably this extra layer of checking could challenge our capability to answer synchronously to the call so also I'm wondering if we should not add capability to answer asynchronously to geofencing request.
Originally posted by @bigludo7 in https://github.com/camaraproject/DeviceLocation/issues/133#issuecomment-2072579733