- From: Max Froumentin <maxfro@opera.com>
- Date: Mon, 5 Oct 2009 11:33:14 +0200
- To: Robin Berjon <robin@robineko.com>
- Cc: "Tran, Dzung D" <dzung.d.tran@intel.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
On 5 Oct 2009, at 11:15, Robin Berjon wrote: > On Oct 4, 2009, at 17:27 , Tran, Dzung D wrote: >>>> - Compass >>> >>> As in the existence or absence of a Compass device, right? But not >>> providing a heading, since that would overlap the geolocation >>> specification. >>> If that's right, then add: Geolocation device >> >> Providing access to Geolocation information via the System Info & >> Events API is logical, although it would be duplicitous. > > I think that what Max meant here was that the SIE would expose > whether geolocation and compass capabilities are present, not the > actual information. Correct. > >> I'm not sure the Geolocation API has in mind the use case where >> orientation info comes from a compass rather than being >> extrapolated over time from GPS coordinates. The geo API is agnostic about the device that provides geolocation, and will just report one value for "heading", which it is up to the implementation to figure out. >> If we choose to provide compass data via the Geolocation API, it >> should have an orientation Use Case and an orientation Requirement >> added, e.g. requirement 6.2.4 should be modified to read: " The >> Geolocation API MUST allow an application to register to receive >> updates when >>either the position or the heading<< of the hosting >> device changes." So maybe the geolocation specification should be refined, specifically the statement below to make it clear the position includes heading, and even speed. "[watchPosition] then must continue to monitor the position of the device and invoke the appropriate callback every time this position changes." Max.
Received on Monday, 5 October 2009 09:33:50 UTC