- From: Dave Raggett via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 May 2015 18:05:01 +0000
- To: public-device-apis@w3.org
Thanks for the list of built-in sensors. I can understand the idea of creating an API that scales to the needs of these particular sensors, but beyond that a more flexible approach would be appropriate. For sensors delivering continuous data, it is likely that the history of that data is what the app will want to process (e.g. an ECG waveform), and the latest value won't be particularly important. The way that continuous data is delivered will vary from one sensor to another. For example, values at fixed intervals, or at timestamped points in time? You might get parameters describing a piecewise approximation to time changing values. This makes it important to get access to metadata describing a particular sensor, or a set of sensors when data is streamed from multiple sensors. This calls for a flexible approach to representing metadata, and I am curious as to how you intend to support that. The Web of Things starts with the discovery of a URI for a thing as a basis for accessing its metadata. The platform (e.g. server or browser library) can then use this to create a proxy object in the script's local execution environment, decoupling scripts from the underlying bindings to protocols and device drivers. -- GitHub Notif of comment by draggett See https://github.com/w3c/sensors/issues/18#issuecomment-103150891
Received on Monday, 18 May 2015 18:05:05 UTC