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

Re: updated editor's draft of the Geolocation API specification

From: Lars Erik Bolstad <lbolstad@opera.com>
Date: Tue, 09 Jun 2009 12:58:29 +0200
Message-ID: <4A2E4055.5060903@opera.com>
To: Andrei Popescu <andreip@google.com>
CC: public-geolocation <public-geolocation@w3.org>
Andrei Popescu wrote:
> Hi Lars,
>
> On Mon, Jun 8, 2009 at 10:29 PM, Lars Erik Bolstad<lbolstad@opera.com> wrote:
>   
>> But we also have two open issues that should be closed before we go to last
>> call:
>>
>> ISSUE-6: enableHighAccuracy, "Is enableHighAccuracy the right naming for
>> this attribute? Should we have it at all?"
>> We seemed to have consensus on renaming it, with a few members in favour of
>> dropping it completely.
>> Allan Thomson proposed to replace it with "reducedPowerHint", along with a
>> definition:
>> http://lists.w3.org/Archives/Public/public-geolocation/2009Apr/0034.html
>> Is anyone against resolving ISSUE-6 by replacing enableHighAccuracy and its
>> definition with Allan's proposal?
>>
>> ISSUE-7: heading & speed, "Should heading & speed be moved out of the
>> Coordinates interface?"
>> Given that Geolocation API v2 will have support for address, should
>> 'heading' and 'speed' attributes be moved out of the Coordinates interface?
>> They could go to a separate interface (e.g. Velocity) so that implementation
>> can return any combination of (coords, velocity, address).
>>
>> There hasn't really been any discussion on this issue. Are there any
>> objections to moving the "heading" and "speed" attributes out of the
>> Coordinates interface and into a new Velocity interface?
>>
>>     
>
> Given we're about to have a lot of shipped implementations (iPhone,
> Firefox, Chrome/Android/Gears, Iris, and others), I would like to
> propose we keep the spec as it is and move these issues to V2. Since
> we're talking about renaming a boolean and moving two attributes to a
> new interface, I think we can safely live with what we have and avoid
> making all these implementations incompatible from the day they come
> out. I realize this is a risk they took when they decided to implement
> a draft, but in this case I don't think the two issues are important
> enough to justify a compatibility break.
>
> Thanks,
> Andrei
>   
I agree. And you can add Opera to that list, btw :-)

Lars Erik
Received on Tuesday, 9 June 2009 10:59:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:56 UTC