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

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

From: Andrei Popescu <andreip@google.com>
Date: Tue, 9 Jun 2009 10:53:08 +0100
Message-ID: <708552fb0906090253l1f6f6b97td17c91187bfa397b@mail.gmail.com>
To: Lars Erik Bolstad <lbolstad@opera.com>
Cc: public-geolocation <public-geolocation@w3.org>
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.

Received on Tuesday, 9 June 2009 09:53:43 UTC

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