12:00:31 RRSAgent has joined #wot-script 12:00:31 logging to https://www.w3.org/2022/02/21-wot-script-irc 12:00:38 meeting: WoT Scripting API 12:00:44 present+ Kaz_Ashimura, Jan_Romann 12:01:34 dape has joined #wot-script 12:02:22 zkis has joined #wot-script 12:02:28 present+ Daniel_Peintner 12:02:31 chair: Daniel 12:02:40 JKRhb has joined #wot-script 12:02:51 cris has joined #wot-script 12:03:47 present+ Zoltan_Kis 12:04:48 present+ Cristiano_Aguzzi 12:05:15 scribenick:zkis 12:05:32 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#21_February_2022 12:05:57 Mizushima has joined #wot-script 12:06:16 Topic: approving previous minutes 12:06:25 DP: looks OK to me 12:06:47 ... some minor indentation issue 12:07:05 ZK: it's fine 12:08:41 DP: there was one action and it's been done 12:08:48 DP: no objections, minutes approved 12:08:54 present+ Tomoaki_Mizushima 12:09:11 i|looks|-> https://www.w3.org/2022/02/14-wot-script-minutes.html Feb-14| 12:09:35 DP: new publication only after the discovery is agreed and reworked 12:09:52 DP: on open PR from Jan 12:10:12 Jan: it's a draft and will stay as work in progress 12:10:39 Topic: Issues 12:11:01 DP: Mostly about aligning discovery 12:11:35 ... waiting until outstanding PRs are merged in the Discovery spec 12:11:54 DP: Also, we need to align with the Architecture spec (terminology) 12:12:15 ... also, if we need changes in Architecture spec, we need to raise now 12:12:26 ... so everyone please take a look 12:12:37 Subtopic: issue 363 12:12:48 -> https://github.com/w3c/wot-scripting-api/issues/363 12:14:02 q+ 12:14:33 rrsagent, make log public 12:14:37 rrsagent, draft minutes 12:14:37 I have made the request to generate https://www.w3.org/2022/02/21-wot-script-minutes.html kaz 12:14:46 ZK: currently since we don't have an API for composite TD consuming, we need to consume as one TD and make it simple for the apps 12:15:18 CA: the outstanding PR is specifying this part, we need decision how we want in the future 12:15:31 ... in PR 272 12:15:54 i|issues/363|issues/363 Consuming composited Thing Description| 12:15:56 Subtopic: 354 12:16:05 -> https://github.com/w3c/wot-scripting-api/issues/354 12:16:09 q? 12:16:12 ack c 12:16:42 DP: we discussed this in the main call several times 12:16:57 ... I don't seem to have the right understanding, it looks OK 12:17:00 s|issues/354|issues/354 Conformance section necessity| 12:17:22 q+ 12:18:05 ack k 12:18:10 KA: the point is the WoT group wants to publish the Scripting API spec as a Note but with normative portions, that should be OK if the group makes such a resolution. 12:18:28 DP: for me it is important to have the conformance section, to refer to it 12:20:15 ZK: same here, we have 3 conformance classes that would be hard to express in other ways. 12:20:39 DP: it also depends on how the other task forces will publish the Notes they are working on. 12:21:07 KA: the groups chair said everyone should read the Scripting API Note and make an informed resolution on 23 February main call. 12:21:41 KA: we need to follow the procedure and have the whole WG's resolution 12:21:50 DA: that sounds good 12:22:32 s/the point is the WoT group wants to publish the Scripting API spec as a Note but with normative portions/the point here is whether the WoT WG as a whole wants to publish the Scripting API spec as a Note including normative portions or not/ 12:22:45 s/, that/. that/ 12:23:50 Subtopic: issue 364 12:23:53 -> https://github.com/w3c/wot-scripting-api/issues/364 12:27:07 ZK: the only problem with async iterables is lack of support in small JS runtimes, but it's supported in Node.js and the browser, too 12:27:18 q+ 12:28:19 CA: with notifications we have events (async), but in this case we have as result a TD, and it's less probabilistic (e.g. a list of TDs) 12:28:30 ... in this case, the async iterators work well. 12:29:01 ... since the use case is different from Subscription, it is justified to use async iterators 12:29:30 Jan: canceling discovery should also be supported 12:29:53 ... the previous design had an issue with the implementation, async iterators don't have that problem and the API is cleaner as well 12:30:53 i|364|364 Using a callback-based approach for Discovery?| 12:31:44 ZK: the discovery object is still a subscription, but now instead of next() method it is iterable - but still has the stop() method. 12:32:14 DP: the direct case with separate method looks like a fetch, not like discovery 12:33:03 ZK: is there any extra semantic info with direct discovery? 12:33:31 CA: in principle it is an introduction mechanism 12:33:56 ZK: that is a difference we need to align between the task forces 12:34:50 CA: yes, previously it was a fetch, but now it's like an introductory mechanism in the Discovery spec 12:35:42 DP: if you call a direct discovery, you get one TD, which can be the TD of a directory 12:36:51 ZK: then we should define another API for introduction and not name it "direct" 12:37:50 ... but we could keep the direct method 12:38:13 CA: yes, it is more like a use case for "direct" fetch of a TD 12:39:09 ZK: so we need to align now these use cases (direct, directory, introduction) and maybe the API needs changing 12:39:19 q+ 12:39:21 DP: if I call discover(), I get TDs of Things 12:39:34 ... but now we can also get a list of directories (as well) 12:40:04 q? 12:40:08 CA: yes, this is under work now in the discovery TF - and the behaviour is optional 12:40:25 ... maybe indeed we should wait a bit until this is decided 12:40:28 ... we need to keep a close eye on this 12:40:58 Jan: maybe the direct method could behave differently, depending on the return type (TD or directory) 12:42:00 ZK: let's try to cleanly separate the use cases vs API, and not multiplex based on returned content 12:43:01 DP: we should stop here and think about it 12:44:00 CA: if we need to check the returned content, we cannot do streaming TDs since we need to wait and decide and act 12:45:57 ZK: we can do streaming use case with the current API, using a TD that specified a content type as a binary (streamed) TD content, and fetch with the current API 12:47:08 rrsagent, draft minutes 12:47:08 I have made the request to generate https://www.w3.org/2022/02/21-wot-script-minutes.html kaz 12:47:31 Subtopic: issue 384, aligning discovery and scripting 12:47:53 DP: we need to be aware of the differences and communicate to the Discovery TF 12:47:59 -> https://github.com/w3c/wot-scripting-api/issues/384 12:48:25 Subtopic: issue 382 github actions 12:48:31 -> https://github.com/w3c/wot-scripting-api/issues/382 12:50:05 CA: we need to do the proper sequence for the actions - in theory they could run in parallel, but there are issues 12:52:16 DP: the sync should succeed, so if one triggers the other, it should be fine 12:52:25 CA: OK, will settle that 12:53:19 Subtopic: package lock file 12:53:36 DP: there should be one lock file, and none in the subdirectories 12:53:48 ... I can provide a PR 12:53:54 CA: it's mainly for the CI 12:54:14 ... no dependency, just development tools 12:55:13 DP: need to leave earlier today 12:55:20 s/384/384 Align discovery and scripting/ 12:55:24 adjourned 12:56:05 s/382/382 Sync ThingModel action failed/ 12:56:11 rrsagent, draft minutes 12:56:11 I have made the request to generate https://www.w3.org/2022/02/21-wot-script-minutes.html kaz 12:56:18 Mizushima has left #wot-script 12:57:59 i|there should be|-> https://github.com/w3c/wot-scripting-api/issues/379 Issue 379 - ThingModel TypeScript defintition misses package-lock.json| 12:58:03 rrsagent, draft minutes 12:58:03 I have made the request to generate https://www.w3.org/2022/02/21-wot-script-minutes.html kaz 12:58:43 s|/382|/382 Issue 382 -| 12:59:34 s|/364|/364 Issue 384 - Using a callback-based approach for Discovery?| 12:59:50 s|/354|/354 Issue 354 -| 13:00:23 s|/363|/363 Issue 363 - Consuming composited Thing Description| 13:00:32 rrsagent, draft minutes 13:00:32 I have made the request to generate https://www.w3.org/2022/02/21-wot-script-minutes.html kaz