W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2010

Re: DeviceOrientation comments

From: Dean Jackson <dino@apple.com>
Date: Fri, 23 Jul 2010 22:59:01 +1000
Cc: public-geolocation@w3.org
Message-Id: <241BD3E0-7691-461D-BEAA-86860C8665C7@apple.com>
To: Maciej Stachowiak <mjs@apple.com>

On 23/07/2010, at 6:18 PM, Maciej Stachowiak wrote:

> On Jul 22, 2010, at 9:31 PM, Dean Jackson wrote:
>> On 22/07/2010, at 9:53 PM, Dean Jackson wrote:
>>> My main comment/proposal is that Accelerometer Event should include the ability to return rotation around the 3 axes. 
>> I've realised this is pretty silly. A new event type is a better idea.
>> interface GyroscopeEvent : Event {
>> readonly attribute double xRotationRate;
>> readonly attribute double yRotationRate;
>> readonly attribute double zRotationRate;
>> void initGyroscopeEvent(....
>> }
>> This way implementations without gyroscopes don't need to waste space sending null values. Similar to AccelerometerEvents, if you can't support it, you fire one event with all nulls.
> A) It's not really a significant waste of space to have three more fields in a transient event.

My thinking was that there may be cases where you only want one but not the other, and this would save turning the hardware "on". The two pieces of hardware might also have significantly different sampling rates, so you could get into situations where the gyro is giving you data but the accelerometer component is null at that instant (or visa versa).

> B) For applications that care about both of these, are they likely to benefit from being able to process both accelerations and rotation rates at the same time? If so, one event will be more convenient for the developer.

I can only speak to Apple's API, but it allows you to separate or join, so I assume there are use cases both ways.

> C) If an event is not supported, it seems more sensible to me if the implementation doesn't fire it at all, rather than repeatedly firing a fake event with no useful values.

I was just copying what the existing spec says about Accelerometer. I assume this was the solution for indication that the implementation supports the event but the hardware does not. There needs to be a way to detect that, otherwise you can't tell between a temporarily stationary device and an unsupported one.

Received on Friday, 23 July 2010 12:59:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:57 UTC