Re: application facing lifecycle, data and interaction model for things

Hi Dave,

Thanks, I now see the point with using streams as an abstract sequence of values or state updates. I wonder if we could generalize the concept of a stream to include any sequence of notifications? If so, we could include events in the definition of what can be sent in a stream. Note that the HTTP EventSource model and SSE protocol include both concepts of "event" and "data" chunks sent over the wire asynchronously. The mediatype used is "text/stream", which I assume could be extended to include representation formats, e.g. application/json+stream or some similar signaling.

It seems like this could be a good abstraction to describe the way scripts register callbacks for notifications. It would work for both events and state/value updates (ref. the other discussion on RESThooks, etc.). The abstraction would be that in order to receive a stream of asynchronous notifications, the script uses the "stream" type to reference the resource. This could map to CoAP Observe, HTTP SSE, and MQTT Subscribe depending on the protocol binding. The runtime or library would handle the subscribe/notify state machine and, for example, deliver progress updates to a long running promise.

If the notifications are stored in a collection or array, we could also provide the interface to retrieve history or derived quantities using a retrieve operation.

Best regards,

MIchael

> On Apr 28, 2016, at 2:04 AM, Dave Raggett <dsr@w3.org> wrote:
> 
> I further see the need for having things and streams as first class types. This is just another way to say that values can be things or streams, which can be passed through events, assigned to properties, passed to or returned by actions. As far as a programming language goes a thing is just an object with properties, methods and a means to register event handlers. Passing a thing as a value is essentially passing a reference to an object.  Note that the platform is responsible for creating this object based upon information passed through the messaging protocols. In practice, this is likely to involve passing a URI for the thing’s description, and for the receiving platform to retrieve this description in order to construct the corresponding object.
> 
> Streams provide an interface for dealing with a time sequence of values  corresponding to a specific type. In some cases, each value in the sequence may be associated with a time stamp. The stream interface may provide a means to  access a history of values or to request the interpolated value at some time in between adjacent samples.  Examples of streams include the data stream reported by an electrocardiogram, or the trajectories for the  joint positions for a robot arm to carry out a specific movement. Streams can thus be used for sensing and actuation.
> 
> Borrowing from the Web, an event has a name and carries a single value, which could be atomic or compound. There is a standard way to register or unregister a handler for a given event name.
> 
> Similarly for actions: when invoking an action you may be able to pass one or perhaps more values. Given that values can be compound, a single value will normally be sufficient. Actions have to be asynchronous given that they may result in processing on a remote device.  I believe it is appropriate for actions to return a sequence of zero or more values.
> 
>