Re: skeleton Geolocation API

On Thu, Jun 26, 2008 at 2:08 PM, Andrei Popescu <andreip@google.com> wrote:
> Hi all,
>
> Thanks for the feedback! I've updated the draft editor spec:
>
> - Removed the reverse geocoding.
> - Removed locationResolvers property.
> - Attempted to clarify the definition of the getCurrentPosition() and
> watchPosition().
> - Mentioned that we default to WGS84 for the coordinate system and
> added an issue about supporting other geodetic systems.
> - Added links to the mailing list discussions around "enableHighAccuracy".
>
> I'd be very grateful if you could have another look and let me know
> what you think, especially if there are any fundamental changes that
> are still needed (things around the overall API design, things that
> should be addressed or should be left out, etc).

Nice. I only have nits.

<snip>
The lastPosition attribute must return the last Position object that
was acquired by the implementation, or null if no such object exists.
On getting, this attribute must return a previously cached value and
the implementation must not attempt to acquire a new Position object.
</snip>

I don't think "acquire" is really defined anywhere. Maybe we should
just say that this API is designed to be fast and synchronous and that
the implementation should not do expensive IO inside this getter.

<snip>
The getCurrentPosition() takes either a PositionCallback object or a
PositionOptions object as a parameter. When called, it must
immediately return and then asynchronously acquire a new Position
object.
</snip>

Maybe make it less mandatory that this actually get a new fix.
Implementations will want to throttle this.

<snip>
PositionOptions objects are regular ECMAScript objects and must be
created using the ECMAScript object literal syntax.
</snip>

I don't think that the spec should require this to be an ECMAScript
object, only allow it to be. Especially it should not be required to
use ECMAScript object literal syntax. It should be OK to pass any
ECMAScript object here that has the specified members.

<snip>
The successCallback attribute represents the callback that is invoked
by the Geolocation object methods after successfully acquiring a fresh
position fix.
</snip>

I think this could be simplified, like this:

The successCallback attribute contains a callback that is invoked when
position acquisition succeeds.

Similar with errorCallback.

Also, all of these attributes are optional and can be null/undefined,
as permitted by the language.

<snip>
The altitude attribute denotes the height of the position, specified
in meters above the [WGS84] ellipsoid.
</snip>

We need to be explicit about what we're going to do when the
implementation does not have altitude information.

As a start, I think altitudeAccuracy field should be zero. As a
convenience to ECMAScript developers, I also think that the
Position.altitude field should be <null> in this case.

- a

Received on Thursday, 26 June 2008 21:33:32 UTC