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

Re: Thing descriptions for Server Sent Events?

From: Dave Raggett <dsr@w3.org>
Date: Wed, 16 Nov 2016 12:21:25 +0000
Cc: Fabrice Desré <fabrice@mozilla.com>, Public Web of Things IG <public-wot-ig@w3.org>
Message-Id: <40AB8E37-820B-4DF0-A272-030EF6E4333E@w3.org>
To: Michael Koster <michaeljohnkoster@gmail.com>

> On 15 Nov 2016, at 23:41, Michael Koster <michaeljohnkoster@gmail.com> wrote:
> 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.

It would easy enough for SSE messages to include a status code where appropriate as part of the message body, but note that as SSE is unidirectional (server to client), the client would use HTTP requests for passing messages to the server, and this can take advantage of the regular REST patterns.

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

SSE is based upon UTF-8 text based messages, e.g. JSON. You could base64 encode binary blobs if needed. The server that hosts the SSE stream gets to define the format and meaning of the messages. The thing description needs to provide sufficient metadata for a consuming platform to figure out how to handle SSE. Given the overall principle of decoupling applications from the protocols, the consuming platform will need to interpret the message content and map this to thing property updates, thing events and thing action responses, etc.

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

Yes, it is just one example. From a business perspective, streaming data to the cloud is very important, e.g. for proactive maintenance. The Web of things needs to cater for the streaming protocols companies want to use or are using. This is why we need to involve the companies working on this, e.g. cloud IoT platforms, so that our standards are driven by commercial needs.

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

Received on Wednesday, 16 November 2016 12:21:41 UTC

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