Bug: use server metadata to determine which protocols/uris/encodings to use with it

[draggett]

The current code assumes that the server supports WebSockets on the following URI:

 'ws://'  + hostname  + ':8080/webofthings'

This needs to be replaced by querying the server to determine which protocols, URIs and encodings it supports. This process starts with a URI for a thing on the server. That URI is then transformed to access a well known path:

 /.well-known/protocols

A GET on this should return a JSON object with the desired info. This still needs to be defined!

Note: URI schemes for thing descriptions are limited to protocols supporting GET, e.g. HTTP and CoAP.

[iapain]

@draggett I can take over this. Is there any registry or explanation for /.well_known/protocols file content? How about a fallback if file is missing on webserver.

[draggett]

Thanks. CoAP uses /.well-known/core as a basis for resource discovery, see RFC 6690. The idea of /.well-known/ is defined in RFC 7851 which describes a process for registering well known URIs.

I was thinking about a JSON based format like:

{
“ws” : {
“uri” : “ws://www.example.com:8080/webofthings”
},
“http” : {
“uri” : “http://www.example.com:8888/webofthings”
}
}

Using a JSON object for each protocol provides plenty of extensibility. We can iteratively evolve the format as we better understand the requirements through experience with integrating support for a range of protocols.

The “uri” above is the URI for the messaging end point. A client accesses this end point to initiate messaging. The details will vary according to the protocol. Web Sockets provides for asynchronous bi-directional messaging. HTTP just supports request-response. To allow for asynchronous call backs, we either need to use polling, or to provide a matching end point for the target server to push messages to the client. This matching end point would be passed as part of the session initiation request.

The format could be used to provide server specific security metadata for messaging, e.g. what credentials are needed (we need more work on security to understand what this metadata should be). Likewise for communication metadata.

The protocols resource could be retrieved the first time a client needs to access a thing on another server. One challenge is how to address situations where the protocol resource is updated. If the client has an existing messaging channel, this could be used to signal this change.

A point to remember is that .well-known is fine for protocols like HTTP or CoAP, but further work would be needed to address topic based pub-sub protocols like MQTT.

What do you think?

[iapain]

HTTP, CoAP and ws should be fine with above format. I've to look into MQTT.

Above structure is flexible enough to extend it further. Shouldn't we call it /.well-known/protocols.json. If we adapt RFC 6690 like functionality then webserver should implement query on json as well. To keep it simple we can just use JSON which you defined in above example.

I'll implement it the way we discussed above.

[draggett]

You're probably right about including the file extension, e.g. it will ensure that the HTTP server provides the right MIME type.

[iapain]

@draggett Now moving forward how client should choose which protocol should be used for example incase ws, coap or http?

Are we going to implement coap and http server as well?

[draggett]

Good question! One simple idea is to add a field with a numeric value that defines a preference order.

For the NodeJS server, yes the aim is to support a wide range of protocols, e.g. as a basis for interoperability testing with other servers.

[bubbafat]

There was a discussion about this on the pull request @iapain sent - my pull request is simply for discussion of another approach.

[iapain]

@draggett

{
   “ws” : {
      "uri" : "ws://www.example.com:8080/webofthings",
      "priority": 1
   },
   “http” :  {
      "uri" : "http://www.example.com:8888/webofthings",
      "priority": 2
   }
}

Does this makes sense?

@bubbafat I totally agree with you regarding transport independent api @draggett what's your opinion about it? This will allow us to abstract all boilerplate and build a clean api on top of it.

[mkovatsc]

Instead of cooking up a custom JSON format, you could simply use application/link-format. The information about the protocol is given in the URI scheme. Link attributes can be used to give priority hints (in the end, it is the application that decides which link to follow).

Example:

<ws://www.example.com:8080/webofthings>;pri=1,<http://www.example.com:8888/webofthings>;pri=2

There is also a JSON serialization for Link-Format in the making: https://tools.ietf.org/html/draft-ietf-core-links-json-02

Content negotiation then can give you the preferred format (please no file extensions...).

[draggett]

On 27 Jun 2015, at 14:12, Matthias Kovatsch [email protected] wrote:

Instead of cooking up a custom JSON format, you could simply use application/link-format. The information about the protocol is given in the URI scheme. Link attributes can be used to give priority hints (in the end, it is the application that decides which link to follow).

Example:

ws://www.example.com:8080/webofthings;pri=1,http://www.example.com:8888/webofthings;pri=2
There is also a JSON serialization for Link-Format in the making: https://tools.ietf.org/html/draft-ietf-core-links-json-02 https://tools.ietf.org/html/draft-ietf-core-links-json-02
Content negotiation then can give you the preferred format (please no file extensions...).

That’s worth thinking about. We have a lot of communications metadata to express, so it is worth experimenting to see what will work best. Given the underpinning of Linked Data, there are a variety of serialisations to consider.

—
Dave Raggett <[email protected] mailto:[email protected]>

[draggett]

Some discussion in the WoT IG resulted in the following approach:

{
   "protocols" : {
      “ws” : {
         "uri" : "ws://www.example.com:8080/webofthings",
         "priority": 1
      },
      “http” :  {
         "uri" : "http://www.example.com:8888/webofthings",
         "priority": 2
      }
   }
}

where the "protocols" object was added to make it easier to add non protocol related server metadata.

My plan would be to introduce transport layer NodeJS modules, with one such module for each protocol. A server wishing to communicate with another server would first download that server's metadata and use that to determine how to configure thing/proxy getters and setters to the appropriate transport layer module. These modules would expose a common API for registering and unregistering things and proxies, handlers for property getters and setters, and for actions and their responses.

The first step would be to do this for HTTP and Web Sockets. In future additional modules would be added for CoAP, MQTT and XMPP.