11:02:56 RRSAgent has joined #wot-script 11:02:58 logging to https://www.w3.org/2022/04/04-wot-script-irc 11:02:59 cris has joined #wot-script 11:04:27 meeting: WoT Scripting API 11:05:01 Mizushima has joined #wot-script 11:06:22 present+ Kaz_Ashimura, Daniel_Peintner, Jan_Roamann, Zoltan_Kis 11:08:03 scribe: zkis 11:08:43 Topic: past minutes 11:08:52 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#4_April_2022 11:08:58 DP: we discussed discovery and consequences to Scripting 11:09:12 i|we dis|-> https://www.w3.org/2022/03/28-wot-script-minutes.html Mar-28| 11:10:17 DP: no objections, meeting minutes accepted 11:10:34 Topic: issue 376 11:10:44 -> https://github.com/w3c/wot-scripting-api/issues/376 11:10:50 cris has joined #wot-script 11:11:04 DP: about alignment with Architecture doc 11:11:05 present+ Cristiano_Aguzzi, Tomoaki_Mizushima 11:11:28 DP: I provided feedback and a PR with small changes 11:12:17 CA: we can close it and check back later 11:12:33 Topic: issue 388 11:12:40 rrsagent, make log public 11:12:41 -> https://github.com/w3c/wot-scripting-api/issues/388 11:12:46 rrsagent, draft minutes 11:12:46 I have made the request to generate https://www.w3.org/2022/04/04-wot-script-minutes.html kaz 11:13:19 DP: sometime we are not sure we get back any data from an interaction 11:13:20 chair: Daniel 11:13:21 rrsagent, draft minutes 11:13:21 I have made the request to generate https://www.w3.org/2022/04/04-wot-script-minutes.html kaz 11:13:33 q+ 11:13:38 DP: we could look at DataSchema, but return value might be optional 11:13:55 DP: the idea is to tell the scripts by a flag if there is any data at all 11:14:20 ack cris 11:14:35 CA: wondering if that is useful 11:15:26 ... we could have 2 options: when reading value, we get undefined, or we read the stream 11:15:35 q+ 11:15:41 q+ 11:16:00 CA: so IMHO this is not strictly needed, but would delay exposing this until a real need arises 11:16:33 DP: we had a too generic interface that didn't go in the DataSchema, maybe an implementation issue 11:16:58 q- 11:18:15 q+ 11:18:30 q- 11:18:35 ZK: in InteractionOutput interface we can use the nullable 'data' property to tell there is no data 11:18:41 q+ 11:20:21 ZK: we could also include an extra step in the value() function to return NoData or similar 11:21:56 ack zkis 11:22:54 CA: there could be cases of empty stream, that should return undefined 11:23:04 ZK: but we would use the reject path to tell there is no data 11:23:08 CA: right 11:24:02 ZK: so we need to check the steps for value() and reading data 11:24:58 DP: we need examples 11:25:55 CA: ConsumedThing examples 11:26:08 DP: maybe we need to look into the implementation 11:26:57 ZK: is there any validation in node-wot to check if the spec is implemented correctly? 11:27:00 q+ 11:27:16 DP: there are tests but no formal process for that yet 11:27:45 ack cris 11:28:08 CA: yes, we have some unit tests and we need to review them to make more close to the spec 11:28:47 ... but how to ensure the tests themselves are correct - we still need human code review 11:29:07 ... then the test suite can be used by other APIs as well 11:30:38 DP: bindings make it difficult 11:30:54 Jan: and only for consuming things, not for exposing 11:31:10 DP: again the question of REC track raises, together with tests 11:31:37 ... for time being, we seem to agree we don't need a separate flag, but revisit the algorithms 11:31:47 ZK: yes 11:31:55 DP: ok, I am fine with that. 11:32:10 Topic: issue 392 11:32:20 -> https://github.com/w3c/wot-scripting-api/issues/392 11:32:38 DP: to fill use cases concerning Scripting API 11:33:33 JKRhb has joined #wot-script 11:34:00 ZK: scripting API is a tool, not a use case itself 11:34:00 ... it can be used as a tool to implement other use cases 11:34:01 zkis has joined #wot-script 11:34:22 DP: so what should we do here? 11:34:28 ZK: IMHO nothing - maybe clarify the expectations 11:34:44 CA: same here, more information is needed 11:36:22 Jan: one distinction we could make is machine-to-machine and machine-user interactions 11:38:24 CA: isn't this about requirements? 11:39:08 ZK: but scripting is not specific to these use cases, since it's generic and tied to the TD spec 11:40:46 Kaz: we need to discuss it in the use cases call 11:41:16 ... each proposal for the use cases themselves should look into all specs and check if the use case is covered 11:41:32 ... and ML's policy is to ask the editors to make that check 11:42:01 DP: so we should ask ML to turn the question not to editors, but to the writers of the use cases 11:42:25 s/each proposal for/each proposer of/ 11:42:55 s/in the use cases call/in the Editors call and the use cases call/ 11:43:04 Topic: issue 395 11:43:11 -> https://github.com/w3c/wot-scripting-api/issues/395 11:43:39 DP: about closing connections from ConsumedThing 11:44:10 DP: scripts should be able to close a connection or clean up 11:45:14 ZK: on ExposedThing we have destroy() 11:45:20 ... and start() 11:45:56 CA: we can use separate connection on each request 11:46:14 DP: how do we do with a websocket? 11:46:40 ZK: is it enough to have destroy() on ConsumedThing as well? 11:48:15 CA: since we need a Form for interactions, we cannot really make a connection when constructing ConsumedThing 11:48:54 DP: if we had destroy(), it would make the object unusable? 11:49:48 CA: semantically speaking yes, a new consume is needed, but technically we can implement it to reconnect 11:50:05 ZK: we can name it other than destroy() 11:50:29 q+ 11:50:34 DP: if we can reconnect again and again, do we need destroy()? since each impl could have an internal timeout 11:50:40 ... to release all connections 11:51:54 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 11:52:51 q+ 11:52:55 ZK: we can also have start() and stop() methods 11:52:57 q? 11:53:04 ack JK 11:53:31 DP: for websockets, if we close on every request, isn't that too much hitting performance? 11:53:54 q? 11:53:54 Jan: good question 11:54:54 CA: destroy() or stop() can be implemented by the apps, so not strictly needed 11:55:08 ... but for websockets, timeouts are still workarounds to close resources 11:55:29 ... other solutions are not using this 11:55:46 ... we can recommend developers to use timeouts? 11:56:27 ... 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 11:56:28 q+ 11:56:47 CA: we need to handle various scenarios, that's the problem 11:57:06 ... for CoAP is fine to force closing the connection for each request, but for others it might be 11:57:12 ack c 11:57:18 ack JK 11:58:00 Jan: if we have CoAPs, and we connect from constrained device, we should be able to reuse the same connection for multiple requests 12:00:01 ZK: I suggest we take these scenarios each, since there are 2 different policies, freeing up connections as resources, and reusing connections 12:00:25 q+ 12:00:37 q? 12:01:01 Jan: also shutdown() is a possibility 12:01:39 q+ 12:02:00 ZK: shutdown() and destroy() are final, I would use start() and stop(), as also used in other specs 12:02:18 CA: right now the start() method doesn't have any relevance 12:02:20 q- 12:02:37 DP: let's continue on github 12:02:55 adjourned 12:03:30 rrsagent, draft minutes 12:03:32 I have made the request to generate https://www.w3.org/2022/04/04-wot-script-minutes.html kaz 14:14:13 Zakim has left #wot-script 14:57:30 Mizushima has left #wot-script 17:07:02 JKRhb has joined #wot-script 19:30:49 JKRhb has joined #wot-script 19:46:27 JKRhb has joined #wot-script 23:12:56 JKRhb has joined #wot-script