11:01:35 RRSAgent has joined #wot-script 11:01:35 logging to https://www.w3.org/2022/03/28-wot-script-irc 11:01:45 meeting: WoT Scripting API 11:02:35 cris has joined #wot-script 11:03:09 present+ Kaz_Ashimura, Cristiano_Aguzzi, Jan_Romann 11:03:27 present+ Daniel_Peintner 11:03:29 dape has joined #wot-script 11:05:02 Mizushima has joined #wot-script 11:06:26 present+ Tomoaki_Mizushima 11:06:48 scribenick: JKRhb 11:06:57 TOPIC: Previous minutes 11:07:05 -> https://www.w3.org/2022/03/07-wot-script-minutes.html 11:07:16 s/html/html March-7/ 11:07:27 rrsagent, make log public 11:07:28 dp: (Reviews the minutes) 11:07:33 rrsagent, draft minutes 11:07:33 I have made the request to generate https://www.w3.org/2022/03/28-wot-script-minutes.html kaz 11:07:38 ... Minutes look good to me 11:07:54 ... didn't see any issues to correct 11:08:04 ... propose making them public 11:08:18 There are no objections 11:08:27 topic: Quick Updates 11:08:41 dp: I would like to summarize the testfest/plugfest 11:08:48 ... there is still some cleanup to be done 11:09:07 ... unfortunately, we didn't test the Scripting API in its entirety 11:09:37 ... I have the online things running, though, and updated them with the latest node-wot version 11:09:54 ... did anyone else notice anything? 11:10:24 zkis has joined #wot-script 11:10:27 ca: I didn't have time, unfortunately. I was thinking about stress testing node-wot in the context of MQTT 11:11:51 https://pub.dev/packages/dart_wot 11:13:03 jr: I have a scripting API implementation written in Dart that could be tested and be added to the list of implementations 11:15:37 rrsagent, draft minutes 11:15:37 I have made the request to generate https://www.w3.org/2022/03/28-wot-script-minutes.html kaz 11:15:48 topic: PRs 11:15:57 present+ Zoltan_Kis 11:15:59 rrsagent, draft minutes 11:15:59 I have made the request to generate https://www.w3.org/2022/03/28-wot-script-minutes.html kaz 11:16:24 subtopic: PR 381 11:16:35 chair: Daniel 11:16:40 dp: PR is still stalled 11:17:24 i|PR is|-> https://github.com/w3c/wot-scripting-api/pull/381 PR 381 - feat: reintroduce "local" discovery method| 11:17:46 ca: We need to check the current status of the Discovery Specification and look into if "local" should be used 11:18:12 dp: We could also discuss moving discovery to the ConsumedThing class 11:18:42 ... currently we are mostly a wrapper around the Thing 11:18:51 ca: You mean the Directory API, right? 11:20:05 dp: Correct. There were points made by Zoltan if we should base the directory discovery solely on the TD 11:20:33 q+ 11:21:13 ca: We should have another look into the Discovery Specification. Maybe we are a bit too late and can't do anything about it anymore 11:22:00 zk: Discover method is not a complete match for the Discovery Specification 11:23:42 ... currently we only support Directory. You are right that we could get rid of the directory method if we use the TD. For the sake of convenience we could keep it. We need to make clear what is what. 11:24:12 ... our Discovery API is not addressing the introduction phase, therefore we might need a different operational mode 11:24:49 ... we can currently only use the operational mode, i. e. the environment is already set up 11:25:38 ... in order to support local discovery, you need different hooks 11:26:23 q? 11:26:25 ack z 11:26:26 ... interactions with the local hardware are problem in cases like bluetooth 11:27:25 ... for bluetooth, for example, you would need some kind of binding or bridge 11:27:55 q+ 11:28:46 ... the Group needs to decide whether we want to support local discovery or if we should call what we already have "provisioning", for example 11:30:02 dp: If we don't have the local discovery and we only have the Directory then we could get rid of the discover method 11:30:42 ca: I am okay with saying that Discovery methods are out of scope of Discovery API 11:31:55 ... however, how do you let the introduction layer talk to the Scripting layer? 11:33:38 zk: If we have two runtimes, one running in provisioning and one running in operational mode. After the introduction phase you would have an URL that could be passed to the Scripting API. This URL might result in a URL 11:35:02 ... for security reasons we cannot simply query all URLs. We need to formulate use cases for discovery. 11:35:19 ca: Directory is more or less the trivial scenario, real world is more complex 11:36:17 zk: We could have a well known entry point that could map to initializing the Discovery process 11:36:42 ... we should avoid side effects 11:37:07 dp: Let's assume we have the runtimes: Even with the API I am unsure how to describe this 11:37:48 ... how do transfer information from one to the other? 11:38:15 ca: That is what Zoltan was referring to. We currently lack implementations 11:38:55 q? 11:39:06 ... there is an implementation by Ben Francis' (Web Things) that uses multicast DNS 11:39:32 dp: In node-wot we never made it to implementing the discovery methods 11:39:38 q+ 11:39:51 zk: I think the reason was that it was ambigious. 11:40:29 ... current approach is good enough in my opinion, Discovery Object can jumpstart discovery 11:40:33 q+ 11:40:56 ... if we make the Discovery object a Promise than we can jumpstart it 11:42:52 jr: I implemented direct and multicast methods 11:43:23 ack c 11:43:45 zk: Means we can implement it, we should look into how to integrate it in the API 11:44:13 ... we should see how Web Things uses Multicast DNS 11:44:57 ... maybe we can have a convenience method (in node-wot) 11:45:39 ca: Maybe we can use a approach like dependency injection 11:46:15 q? 11:46:34 zk: If we have local we could define what kind of "local" we mean. 11:46:51 ... is very privacy critical, though 11:47:33 dp: Well-known concept might not work out if you have multiple instances of TDs, for example 11:48:48 zk: I think we should take it from a implementation point of view 11:49:36 ... we have direct and multicast, we should see how local can be supported 11:50:27 ... we can include a note in the specification that it is a experimental API 11:50:50 jr: I will try to integrate my discovery approaches in node-wot experimentally 11:51:03 q+ 11:51:08 ack dape 11:53:12 topic: Consumer cleanup behavior 11:53:21 ca: We have a problem in node-wot that CoAP clients are not being closed which causes hanging 11:53:43 ... should we add something like a destroy method to the ConsumedThing? 11:55:12 ... socket is currently not being closed. Problem is not limited to CoAP, however, also relevant for WebSockets, for example 11:57:11 zk: We discussed adding a destroy method to the ConsumedThing a few years ago 11:57:37 ca: If we add a close/destroy method then we would introduce a state 11:59:01 zk: We could specify an InteractionOption that a Consumer should keep connections open. 11:59:36 ca: In the case of HTTP connections are always closed after a request 11:59:57 zk: We can define a default value 12:01:00 dp: In the case of CoAP it might be a library issue. For WebSockets keeping connections open might be useful. For CoAP or HTTP is should not be used. 12:01:46 q+ 12:01:48 ack c 12:01:58 zk: A destructor is useful. The interaction option might actually expose too much procotol-specific information 12:02:17 ack k 12:02:27 ... caching connections in the case of WebSockets etc. will be useful 12:02:49 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#28_March_2022 12:02:53 [adjourned] 12:02:57 rrsagent, draft minutes 12:02:57 I have made the request to generate https://www.w3.org/2022/03/28-wot-script-minutes.html kaz 12:17:35 JKRhb has joined #wot-script 12:20:14 zkis has joined #wot-script 14:00:11 Mizushima has left #wot-script 14:12:54 Zakim has left #wot-script