W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Andrei Popescu <andreip@google.com>
Date: Fri, 27 Jun 2008 20:18:27 +0100
Message-ID: <708552fb0806271218h1ab334b1i2db58cb72dd928e5@mail.gmail.com>
To: "Aaron Boodman" <aa@google.com>
Cc: timeless@gmail.com, public-geolocation@w3c.org, "Nick Brachet" <nbrachet@skyhookwireless.com>, "Doug Turner" <doug.turner@gmail.com>

Hi Aaron,

On Thu, Jun 26, 2008 at 10:32 PM, Aaron Boodman <aa@google.com> wrote:
> <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.
>

In the first paragraph of the Geolocation section I had the following wording:

<snip>
The location information is acquired by applying a user-agent specific
algorithm, creating a Position object, and populating that object with
appropriate data accordingly.
</snip>

I'll make it clear that the lastPosition property is meant to be very
cheap to get.

> <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.
>

Yes, in practice they will probably have to throttle. I think it is
important to make it clear that this will initiate the process of
acquiring a new fix (e.g. start the GPS, do an HTTP request, etc). If
such a process is already underway and a new getCurrentPosition() call
is made, the UA will just queue it to its list of requests to satisfy
when the current process is complete.

> <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.
>

Ah yes, I actually didn't mean to require it. Will fix.

> <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.
>

Thanks for the suggestions, will merge them into the spec.

> <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.
>
+1 for the infinity here.

Thanks,
Andrei
Received on Friday, 27 June 2008 19:19:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT