(3) should fit for https://github.com/w3c/sensors/issues/98, right? we could combine (2) and (3) if needed, but then again there should be two separate pieces of API for each, i.e. coalesced events for (3) and smth like `sensor.latestReadings` for (2) > Additionally, creating this API at a later stage does not absolve us from the necessity of designing our API today so that it is compatible with that future design and stays developer friendly. > For example, if such an API is buffer-based, we'll need a way to express timestamps within buffers. Maybe this is something worth considering upfront. Absolutely agree! I did not mean we should postpone working on it. -- GitHub Notification of comment by pozdnyakov Please view or discuss this issue at https://github.com/w3c/sensors/issues/171#issuecomment-299830890 using your GitHub accountReceived on Monday, 8 May 2017 10:27:22 UTC
This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 12:18:53 UTC