W3C home > Mailing lists > Public > public-wot-ig@w3.org > June 2015

Re: data streams

From: Dave Raggett <dsr@w3.org>
Date: Wed, 3 Jun 2015 11:05:50 +0100
Cc: Magnus Olsson <magnus.olsson@ericsson.com>, public-wot-ig@w3.org
Message-Id: <D2B5EEF9-97C0-45A8-8DE4-A3B911CD89D2@w3.org>
To: Pablo Chacin <pchacin@sensefields.com>

> On 3 Jun 2015, at 10:36, Pablo Chacin <pchacin@sensefields.com> wrote:
> Dave
> >Script developers ony need to know the object model for the sensor and display. The details of the underlying protocols are dealt with 
> >automatically by the server platform. For this to work, we need a standard way to describe data streams as part of the data model for "things".
> What would be the scope of this definition? Only a model of the stream (metadata), or will also propose an api to handle streams. In this later case, I would suggest to take a look at what the reactive programming community has been developing, for example in RxJS (which is very similar to how java 8 handles streams)  

The thing description would need to declare a stream, e.g. the data channels, their types and sampling rates. The server’s scripting environment would expose the stream via an API.  This is strictly speaking a matter for the server platform, e.g. the choice of scripting language and the corresponding APIs it supports. The JavaScript Streams API [1] as suggested by Tobie certainly seems interesting, but I am not sure whether it supports or could be adapted to support timestamps. An object oriented approach would allow you to inspect/control parameters, e.g. how  much time is covered by the stream buffer. I would also like to have methods for querying the value at a specific time, or the sequence of changes within a given time window.  In principle, you could have an API that logs data for very long periods, and hides the way that data is stored in RAM or secondary storage like Flash based memory.

[1]: https://streams.spec.whatwg.org/ <https://streams.spec.whatwg.org/>
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
Received on Wednesday, 3 June 2015 10:05:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 3 June 2015 10:05:58 UTC