[Scripting] Framework-Events to be added

[h0ru5]

According to https://github.com/w3c/wot/blob/master/meeting-results/beijing-f2f/wot-f2f-beijing-scripting-api.md#relationship-between-exposedthing-and-wot-api we decided to add an event source for runtime changes to a Thing's interface structure, such as adding or removing actions and properties.

Also, a runtime could drive a state machine (e.g. defined in statechart-xml) and allow scripts to add handlers to the state transition events as discussed in https://github.com/w3c/wot/blob/master/meeting-results/beijing-f2f/wot-f2f-beijing-scripting-api.md#support-behaviour-definition-by-event-driven-state-machines

[zolkis]

Events could be used in client API. However, in the server API, one request should have exactly one handler, therefore constructs like EventTarget and EventEmitter are not suitable. In the server API IMHO we need to have simple handlers (callbacks) at the serving leaves, i.e. ExposedThings.

But we could have events for non-request type of things (hardware notifications, etc).

[h0ru5]

The question at hand here was in the lines of: "when àddAction is called on the server, how will the client know?", so defining events to be received on the client side (ConsumedThing) could be sufficient.

[egekorkan]

Not relevant anymore, propose closing. Scripting API handles this

[zolkis]

IMHO changing TDs should be done like API changes: new TD (version) out, old one deprecated after a while. Both new and old can be used in the same time in clients, considered as different client endpoints.

Basically we need a mechanism to deprecate old TD's, but I guess that is possible either in the device or in the Thing Directory. In both cases, this needs re-discovery.

[relu91]

This issue seems related to what we are discussing for actions. See w3c/wot-thing-description#899.

[egekorkan]

Discussion should continue in w3c/wot-thing-description#899 , closing.