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

> On 28 Apr 2016, at 22:09, Michael Koster <michaeljohnkoster@gmail.com> wrote:
> 
> 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.

I am proposing streams as part of the type system for the interfaces exposed to applications. I am unclear what you mean when you say “notifications” in respect to the type system?  I agree that there are many possible ways to map streams to protocols with the choice depending on the detailed requirements.

> It seems like this could be a good abstraction to describe the way scripts register callbacks for notifications.

In that sense, notifications are “events” which can carry values which are described by the type system, this would include streams as first class types.

> It would work for both events and state/value updates (ref. the other discussion on RESThooks, etc.).

Given that events and properties have values, they can be used with any permitted type. I see no problem with applications being able to register for notifications when property values are updated. Property updates can be seen as an implicit class of events. Event driven programming has been very successful and widely deployed. It is up to the people designing “things” to determine how to model their service in terms of properties, events and actions.

> The abstraction would be that in order to receive a stream of asynchronous notifications, the script uses the "stream" type to reference the resource.

The stream provides an interface for accessing a sequence of values. The meaning of these values is up to the application semantics.

> 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.

Stream interfaces could support a variety of interface patterns, e.g. blocking and non-blocking reads, call backs, methods for requesting the value at a particular time, methods for requesting the size of a time window for which values are available and so forth.

> 
> 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.

Precisely.

> 
> Best regards,
> 
> MIchael
> 
>> On Apr 28, 2016, at 2:04 AM, Dave Raggett <dsr@w3.org <mailto: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.
>> 
>> 
> 

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>