RE: [Geofencing API] feedback

Having trouble parsing the following example in order to create an issue on GH - can you explain?  

The example you provide tries to execute a remove() on a region, not an actual fence ID.  

Beyond that, it seems that changing "Run the following steps in parallel" to "Run the following steps sequentially" could prevent both remove operations from resolving to true.  This way, a will pass through 2.3 but b will stop at 2.1.   Do you agree?

-Giri

<---Original Text--->

The remove method when invoked MUST run the following steps:

> 1. Let promise be a new Promise.
> 2. Run the following steps in parallel:
> 2.1. If this geofence is not currently in the active geofences associated with a service worker registration, resolve promise with false and abort the remainder of these steps.
> 2.2. Remove this geofence from the set of active geofences associated with the current service worker registration. No more events related to this geofence will be fired after this.
> 2.3. Resolve promise with true.

var region = new CircularGeofenceRegion({
      name: 'myfence',
      latitude: 37.421999,
      longitude: -122.084015,
      radius: 1000
    });
swRegistration.geofencing.add(region)
      .then(
a=region.remove();
b=region.remove();

afaict, the specification allows for these two removes to both resolve to true, or for only one of them to resolve to true.

Specifically a could travel through 1..2.1, then b could travel through 1..2.1, both would decide that it is still active. They would thus advance to 2.2.

-----Original Message-----
From: timeless [mailto:timeless@gmail.com] 
Sent: Wednesday, July 01, 2015 7:35 AM
To: public-geolocation@w3.org
Subject: [Geofencing API] feedback

http://www.w3.org/TR/2015/WD-geofencing-20150604/


> The Geofencing API lets webapps setup geographic boundaries around

set up

> Example 4: Unmonitor a region in response to some other event

"Unmonitor" isn't a word, please use "Stop monitoring"

> A geofence is a tuple consisting of a geographic region, geofence ID and a [sic] include position flag.

an

> A user agent SHOULD NOT reuse the ID from an old geofence for a new one.

If a script intentionally creates and destroys geofences continuously, should a UI shoot it for testing this SHOULD NOT?

> Ask the user whether they allow the webapp to use geofences, unless a prearranged trust relationship applies or the user has already granted or denied permission explicitly for this webapp.

granted or denied permission _for_what_? did you forget to mention "for this api"?

> If not granted, reject promise with a DOMException whose name is "PermissionDeniedError" and terminate these substeps.

Didn't Geolocation get forced to have an infinite timeout instead of a permission denied specifically because this design is sufficiently annoying that it shouldn't be used?

> Set the geofence ID of the geofence to a newly generated value.

If you actually want this value to be something special, then `newly generated value` needs to link to some constraints.

> Resolve promise with a new Geofence instance representing the geofence.

normally one would `construct` a Geofence, initialize its fields, and then resolve something with it....

> The iOS API takes a slightly different approach when permission is denied. It instead always treats registrations as a success, but won't actually track geofences/trigger events unless the user has granted permission.

This is the only sane behavior for privacy/anti-torture reasons (noted earlier).

> When set to false, the position attribute will always be undefined.

normally this is `null` not `undefined`...

> If promise was not resolved, resolve promise with null.

why not reject with notfound?

The remove method when invoked MUST run the following steps:

> 1. Let promise be a new Promise.
> 2. Run the following steps in parallel:
> 2.1. If this geofence is not currently in the active geofences associated with a service worker registration, resolve promise with false and abort the remainder of these steps.
> 2.2. Remove this geofence from the set of active geofences associated with the current service worker registration. No more events related to this geofence will be fired after this.
> 2.3. Resolve promise with true.

var region = new CircularGeofenceRegion({
      name: 'myfence',
      latitude: 37.421999,
      longitude: -122.084015,
      radius: 1000
    });
swRegistration.geofencing.add(region)
      .then(
a=region.remove();
b=region.remove();

afaict, the specification allows for these two removes to both resolve to true, or for only one of them to resolve to true.

Specifically a could travel through 1..2.1, then b could travel through 1..2.1, both would decide that it is still active. They would thus advance to 2.2.

I'm assuming that isn't intended.

interface GeofenceRegion {
    readonly    attribute DOMString name;
};

I think there's often a type field for things like this.

Afaict, this interface isn't used.

dictionary CircularGeofenceRegionInit {
             double latitude;
             double longitude;
             double radius;
};

did you mean for this dictionary to extend: dictionary GeofenceRegionInit ?

> When the object is created, this attribute MUST be set to a GeolocationPoint instance with its latitude and longitude properties set to the same values as those properties in the CircularGeofenceRegionInit dictionary. This represents the center of the circular region. Latitude must be between -90 and 90 inclusive. Longitude must be between -180 and 180 inclusive.

What happens when I set latitude to 200 or longitude to -200?

> If either of these properties is outside these ranges, the constructor will throw a RangeError.

Ah, you threw a rangeerror after you constructed the object. You put the cart before the horse. Please don't do that. Bounds check first.

Also, `will` is not RFC speak

> The downside of doing error checks in the CircularGeofenceRegion constructor is that they will be actual exceptions instead of promise rejections when calling add. Would it make sense to move the validity checks to add?

yes

> If the geofences includePosition attribute is true, set event.position to the current geographical position.

geofence's

> The user agent MAY wait with firing a geofence event until some time 
> has passed after the breach was detected

with firing => delay firing | until firing | to fire

> Upon detecting some situation in which the user agent won't be able to detect future breached of a geofence, the user agent MUST run the following steps:

The UA detects it has a few seconds of battery power left and needs to turn off GPS. It MUST now start all of the registered service workers which have geofences and tell them that it isn't going to be able to monitor their fences?

That seems bad.

> Let event be a new GeofenceErrorEvent, whose geofence attribute is a new Geofence instance representing the geofence for which an error was detected.

The UA didn't detect an error, it detected a problem ("situation") and is generating an error.

> Let event.code be an error code.

Are error codes in style? (I'm pretty sure numeric codes are indeed
*not* in style)

And shouldn't you provide at least a little more instruction about `an error code`?

Received on Tuesday, 7 July 2015 20:31:21 UTC