Re: Thing descriptions for Server Sent Events?

Hi Dave,

I have tried SSE and eventsource in one of my prototypes, with good results. I also use the basic feature (TE=chunked and keepalive) in the Iotivity-Servient to map CoAP Observe/Notify in the HTTP proxy.

It is also mentioned in the explicit protocol binding contribution I made a few months ago, as a way to map asynchronous notification capability to HTTP in the protocol binding along with CoAP Observe and Publish/Subscribe.

One drawback is that there is no status code associated with each response, so the client state machine needs to make some assumptions. This is similar to the case with simple pubsub like MQTT also.  

Also there is some conflict with the use of media types to describe payloads, but I think we can work around that by making a couple more assumptions.

I would prefer that a CoAP observe type handshake was used instead, with an HTTP status line (header) in each response. BUt, since SSE is already used by browsers, I think we're stuck with the design.

For Thing Description to indicate the use of EventSource/SSE I proposed a hypermedia control that instructs the server to use TE=chunked and keepalive connection. There also may be some other controls involved like media type.

There is quite a bit of code framework involved also, but once it's integrates it's not too hard to use.

The next thing I was going to do is API integration with Promises, so that a "progress" handler can be added to be invoked on "events" coming from the server.

BTW, the media type as I recall is called event stream... Is this an example of what you mean when you say "streaming" data?

Best regards,

Michael

PS if this is a communication pattern which, in addition to pubsub, would provide enough flexibility for different WoT use cases, I think we can converge on a set of REST + async protocol bindings that we can go forward with.


> On Nov 16, 2016, at 2:13 AM, Dave Raggett <dsr@w3.org> wrote:
> 
> The Web of Things needs to cater for the platforms and protocols that people are using or likely to use, rather than prescribing what platforms/protocols people should use.
> 
> Server-Sent Events are supported on Firefox, Chrome, Safari, Opera, iOS Safari, Android browser and Chrome for Android, and support is apparently now under consideration for MS Edge. Server-Sent Events is easier to implement in backends than WebSockets, as I‘ve just found out in practice for myself. In addition, Server-Sent Events has a variety of features that WebSockets lack by design, such as automatic reconnection, and event IDs. I am sure that different people will evaluate the pros and cons differently, for one cut, see:
> 
>    http://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource <http://stackoverflow.com/questions/5195452/websockets-vs-server-sent-events-eventsource>
> 
> I am still searching for data on how popular Server-Sent Events are in comparison to WebSockets.
> 
> Yet another approach is “Webhooks”. This is where URLs are passed for use as call backs for pushing data. This design pattern can be used for services that span servers in different clouds. A consumer of a service would pass a Webhook to the provider of that service.  Thing descriptions will need to describe a broad variety of such design patterns.  I would like to see the Web of Things Interest Group publish a study into use cases and requirements, that covers a range of application domains, platforms, protocols and communication patterns.
> 
>> On 15 Nov 2016, at 16:35, Fabrice Desré <fabrice@mozilla.com <mailto:fabrice@mozilla.com>> wrote:
>> 
>> Hi Dave,
>> 
>> What's the advantage over WebSockets though? EventSource is unsupported by IE/Edge (see http://caniuse.com/#search=eventsource <http://caniuse.com/#search=eventsource>) while all browsers support WebSockets.
>> 
>> On 11/15/2016 07:59 AM, Dave Raggett wrote:
>>> Has anyone looked at the thing description requirements for protocol
>>> binding via Server Sent Events, which are supported by most modern Web
>>> browsers? The protocol layers on top of HTTP and keeping the HTTP
>>> connection open, allowing the server to push a sequence of messages to
>>> the client. If the connection dies, the client automatically reconnects.
>>> It is common to use JSON for representing the messages, provided you
>>> steer clear of new lines which have a special significance to the HTML
>>> EventSource objects that browsers provide for handing messages. Server
>>> Sent Events can be considered as an alternative to Web Sockets. Some
>>> form of time stamp (e.g. milliseconds since epoch) would allow a client
>>> to request a history of messages that were missed when the Event stream
>>> connection was dead.
>>> 
>>> I am exploring server side simulation of physical processes, using
>>> Server Sent Events to stream updates to the browser for rendering with
>>> Canvas2D and requestAnimationFrame. This is much easier than setting up
>>> real physical systems, and will enable me to explore a comprehensive
>>> range of ideas for thing descriptions and associated APIs. I will use an
>>> IFRAME element for visualising the physics simulation, where the
>>> enclosing web page provides the user experience for interacting with
>>> things via their thing descriptions. The IFRAME is thus analogous to the
>>> view of a physical system streamed from a webcam.
>>> 
>>> —
>>>   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org> <mailto:dsr@w3.org <mailto:dsr@w3.org>>>
>>> 
>>> 
>>> 
>> 
>> 
>> -- 
>> Fabrice Desré
>> Connected Devices
>> Mozilla Corporation
> 
> —
>    Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>
> 
> 
>