W3C home > Mailing lists > Public > public-wot-ig@w3.org > November 2016

RE: Thing descriptions for Server Sent Events?

From: Mccool, Michael <michael.mccool@intel.com>
Date: Tue, 15 Nov 2016 23:58:13 +0000
To: Michael Koster <michaeljohnkoster@gmail.com>, Dave Raggett <dsr@w3.org>
CC: Fabrice Desre <fabrice@mozilla.com>, Public Web of Things IG <public-wot-ig@w3.org>
Message-ID: <94B1DC03AB76B54E8C86625B98F8506A2FB14DAC@PGSMSX108.gar.corp.intel.com>
Interesting, I’ll definitely have to look into this.   However, if want to want to do is be able to write a protocol description that can support and bridge whatever is out there, we need to add SSE to the mix, but still support WebSockets, MQTT, etc.
Michael McCool

From: Michael Koster [mailto:michaeljohnkoster@gmail.com]
Sent: Wednesday, November 16, 2016 07:41
To: Dave Raggett <dsr@w3.org>
Cc: Fabrice Desré <fabrice@mozilla.com>; Public Web of Things IG <public-wot-ig@w3.org>
Subject: 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<mailto: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


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




--
Fabrice Desré
Connected Devices
Mozilla Corporation

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




Received on Tuesday, 15 November 2016 23:58:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:08 UTC