Re: skeleton Geolocation API

On the lastPosition attribute, I have gotten some feedback from UX  
people that dialog a modal permission dialog for this synchronous API  
is not ideal.  I hate to do this, but could we work through the use  
case for this again.  Is it simply to avoid the cost of an  
asynchronous callback?

Doug

On Jun 26, 2008, at 2:32 PM, Aaron Boodman wrote:

> 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:58:46 UTC