WoT Scripting API

04 April 2022


Cristiano_Aguzzi, Daniel_Peintner, Jan_Roamann, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis

Meeting minutes

past minutes

<kaz> Mar-28

Daniel: we discussed discovery and consequences to Scripting

Daniel: no objections, meeting minutes accepted

issue 376

<dape> https://github.com/w3c/wot-scripting-api/issues/376

Daniel: about alignment with Architecture doc

Daniel: I provided feedback and a PR with small changes

Cristiano: we can close it and check back later

issue 388

<dape> https://github.com/w3c/wot-scripting-api/issues/388

Daniel: sometime we are not sure we get back any data from an interaction

Daniel: we could look at DataSchema, but return value might be optional

Daniel: the idea is to tell the scripts by a flag if there is any data at all

Cristiano: wondering if that is useful
… we could have 2 options: when reading value, we get undefined, or we read the stream

Cristiano: so IMHO this is not strictly needed, but would delay exposing this until a real need arises

Daniel: we had a too generic interface that didn't go in the DataSchema, maybe an implementation issue

Zoltan: in InteractionOutput interface we can use the nullable 'data' property to tell there is no data

Zoltan: we could also include an extra step in the value() function to return NoData or similar

Cristiano: there could be cases of empty stream, that should return undefined

Zoltan: but we would use the reject path to tell there is no data

Cristiano: right

Zoltan: so we need to check the steps for value() and reading data

Daniel: we need examples

Cristiano: ConsumedThing examples

Daniel: maybe we need to look into the implementation

Zoltan: is there any validation in node-wot to check if the spec is implemented correctly?

Daniel: there are tests but no formal process for that yet

Cristiano: yes, we have some unit tests and we need to review them to make more close to the spec
… but how to ensure the tests themselves are correct - we still need human code review
… then the test suite can be used by other APIs as well

Daniel: bindings make it difficult

Jan: and only for consuming things, not for exposing

Daniel: again the question of REC track raises, together with tests
… for time being, we seem to agree we don't need a separate flag, but revisit the algorithms

Zoltan: yes

Daniel: ok, I am fine with that.

issue 392

<dape> https://github.com/w3c/wot-scripting-api/issues/392

Daniel: to fill use cases concerning Scripting API

Zoltan: scripting API is a tool, not a use case itself
… it can be used as a tool to implement other use cases

Daniel: so what should we do here?

Zoltan: IMHO nothing - maybe clarify the expectations

Cristiano: same here, more information is needed

Jan: one distinction we could make is machine-to-machine and machine-user interactions

Cristiano: isn't this about requirements?

Zoltan: but scripting is not specific to these use cases, since it's generic and tied to the TD spec

Kaz: we need to discuss it in the Editors call and the use cases call
… each proposer of the use cases themselves should look into all specs and check if the use case is covered
… and ML's policy is to ask the editors to make that check

Daniel: so we should ask ML to turn the question not to editors, but to the writers of the use cases

issue 395

<dape> https://github.com/w3c/wot-scripting-api/issues/395

Daniel: about closing connections from ConsumedThing

Daniel: scripts should be able to close a connection or clean up

Zoltan: on ExposedThing we have destroy()
… and start()

Cristiano: we can use separate connection on each request

Daniel: how do we do with a websocket?

Zoltan: is it enough to have destroy() on ConsumedThing as well?

Cristiano: since we need a Form for interactions, we cannot really make a connection when constructing ConsumedThing

Daniel: if we had destroy(), it would make the object unusable?

Cristiano: semantically speaking yes, a new consume is needed, but technically we can implement it to reconnect

Zoltan: we can name it other than destroy()

Daniel: if we can reconnect again and again, do we need destroy()? since each impl could have an internal timeout
… to release all connections

Jan: I tried to implement that experimentally to manage hanging CoAP clients, needed to close connections after each request, but needed a method to stop all subscriptions and network activity

Zoltan: we can also have start() and stop() methods

Daniel: for websockets, if we close on every request, isn't that too much hitting performance?

Jan: good question

Cristiano: destroy() or stop() can be implemented by the apps, so not strictly needed
… but for websockets, timeouts are still workarounds to close resources
… other solutions are not using this
… we can recommend developers to use timeouts?
… there are servers to handle thousands of active websockets at a time, it would be good to be able to close sockets when not used

Cristiano: we need to handle various scenarios, that's the problem
… for CoAP is fine to force closing the connection for each request, but for others it might be

Jan: if we have CoAPs, and we connect from constrained device, we should be able to reuse the same connection for multiple requests

Zoltan: I suggest we take these scenarios each, since there are 2 different policies, freeing up connections as resources, and reusing connections

Jan: also shutdown() is a possibility

Zoltan: shutdown() and destroy() are final, I would use start() and stop(), as also used in other specs

Cristiano: right now the start() method doesn't have any relevance

Daniel: let's continue on github


Minutes manually created (not a transcript), formatted by scribe.perl version 185 (Thu Dec 2 18:51:55 2021 UTC).