Updating name and description about node-wot

[mkovatsc]

The various bindings seem to reject update methods to the root resource of each thing where these fields are defined

I assume you try to change the TD from the outside via a request to the TD resource on the Servient. This behavior is not intended. To modify a Thing, you must own it, that is, have access to the runtime sandbox which originally exposed the Thing.

Straight-forward, this means you can only do this from within the script that you run. You can add Actions to the Thing that allow an update via requests from the outside, yet this is custom behavior to be implemented by you.

whether there is a prescribed way to represent other discrete data about the thing.

Any metadata can go into the TD. Exposed Things now behave like simple JavaScript objects and you can assign any value where you want, like the thing["support"] = "none";

thing["manufacturer"] = "ACME Corp.";
thing["serial"] = "4 8 15 16 23 42";

However, for this to fully work, there needs to be a context that defines the terms manufacturer, serial, etc. We are collecting terms that should go into the core vocabulary, so that no additional context is required for common terms. Also see w3c/wot-thing-description#142

[cStorm]

OK, great. I appreciate the link to that issue. That's very much what I was looking for with that part.

On the subject of changing things after the server is running, would the idea be to make your modifications (either to the name, set of properties, etc) and then recall its expose() method? This seemed to work fairly well, but it required changing my ProtocolServer.expose() implementation to check whether it existed already (otherwise it would duplicate the endpoints instead of updating). I didn't see anything similar in the other server implementations, though, so I thought there might be a better way.

[mkovatsc]

Originally, we did not require any specific function call and updates to Things became available instantly. Recently, I refactored to make use of expose(), in particular, for special bridge bindings (binding-oracle, binding-fujitsu) that require some form of handshake to make Things available.

We are still collecting implementation experience how the behavior on updates should be. My assumption at the moment is that any extension and non-breaking change can be done at any time; Changes that break the API, however, should actually result in exposing a new Thing.

Can you provide some feedback if re-exposing the same Thing to apply changes should be made mandatory or any other feedback on the lifecycle?

[danielpeintner]

No further feedback/comment.