Re: [sensors] Agree on coarseness of frequency option

We're tying update frequency to framerates in #4 so moving that 
conversation there.

The contention here relies essentially on the frequency in Hz vs. enum
 (`{ "low", "normal", "high" }`) dichotomy which is characteristic of 
the low level API vs. high level API discussions we've had plenty of 
in the past. The Extensible Web Manifesto tells us to build the former
 first and eventually standardize on the latter if/when common 
patterns emerge or it enables (large) performance wins. So I suggest 
this is what we should do unless there are compelling reasons not to 
("That's what Android does" doesn't fall in that category, imho 
:wink:).

With regards to `frequency` vs. `period` vs. both, it feels like 
`frequency` is very useful while `period` is mostly sugar for updates 
>= 1 per second. Period has the added disadvantage of introducing 
seconds on a platform where things are generally measured in 
milliseconds.

Overall, I suggest we resolve this issue as:

Sensor update rates are set using frequency measured in Hz. 
Additionally, an option to tie update frequency and framerates 
together will be supported depending on the outcome of #4.

-- 
GitHub Notif of comment by tobie
See https://github.com/w3c/sensors/issues/6#issuecomment-100631010

Received on Sunday, 10 May 2015 11:54:27 UTC