Re: Thing descriptions for Server Sent Events?

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

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