Re: Geolocation V2 and backwards compatibility

on requireLatitudeLongitudeAccuracy --

how about:

requireCoords

this would be similar to 'requestAddress'



On Wed, Jun 29, 2011 at 10:10 AM, Steve Block <steveblock@google.com> wrote:
> At the recent face-to-face meeting we talked a lot about how the Geolocation
> V2 API [1] would remain backwards compatible with the V1 API. The additional
> features we'd like to add for the V2 API are ...
> - Support a new civic address property. Implementations must be able to
> invoke the success callback with either a valid civic address, a valid set
> of coordinates or both. This is relevant for implementations which can not
> do a civic address lookup from a set of coordinates, or which rely on
> user-entered civic address data.
> - Support the case where an implementation can provide some coordinate data,
> but not all of the latitude, longitude and accuracy properties, which are
> required in V1. This is relevant for implementations which have access to,
> for example, a speedometer or altimeter, but no source of position
> information. See ISSUE-7 [2] which mentions this problem for the velocity
> components.
> When backwards compatibility was discussed previously [3], one suggested
> approach was to use the DOM hasProperty() API to distinguish between the two
> APIs. This would mean that V2 implementations would have to be backwards
> compatible with webpages written for the V1 API. Webpages using the V2 API
> would use hasProperty() before relying on V2 features. However, we thought
> it would be better to find a solution which avoided the need for versioning.
> This means that in addition to V2 implementations being backwards compatible
> with webpages written for the V1 API, the API needs to be such that webpages
> written for the V2 API still work with V1 implementations.
> To achieve this, we propose the following ...
> - Make the Position.coordinates property optional, as well as its latitude,
> longitude and accuracy properties.
> - Add an optional Position.address property for the civic address, the
> properties of which are all optional.
> - Add a boolean PositionOptions.requireLatitudeLongitudeAccuracy property,
> which defaults to true. When this flag is true, the
> Coordinates.latitude, Coordinates.longitude and Coordinates.accuracy
> properties are all guaranteed to be non-null, and hence Position.coordinates
> is non-null too. This means that the V1 behaviour is maintained and the
> success callback can only be invoked when a valid latitude, longitude and
> accuracy are available. When this flag is false, this restriction is lifted,
> all properties are optional, and webpages have to check each property before
> using it. This allows implementations to provide, for example, a civic
> address or altitude without a latitude and longitude.
> An alternative to the new requireLatitudeLongitudeAccuracy property would be
> to add a new pair of methods, getCurrentPositionV2() and watchPositionV2,
> which would provide the same semantics as if this flag were present and set
> to false.
> Obviously the naming used here is open to discussion and any feedback is
> welcome.
> Thanks,
> Steve
> [1] http://www.w3.org/2008/geolocation/charter/charter-2
> [2] http://www.w3.org/2008/geolocation/track/issues/7
> [3] http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0034.html

Received on Wednesday, 29 June 2011 17:29:36 UTC