11:01:19 RRSAgent has joined #wot-script 11:01:19 logging to https://www.w3.org/2022/08/08-wot-script-irc 11:01:31 meeting: WoT Scripting API 11:02:37 dape has joined #wot-script 11:04:30 cris has joined #wot-script 11:04:33 present+ Kaz_Ashimura, Daniel_Peintner, Zoltan_Kis 11:05:57 MIzushima has joined #wot-script 11:08:11 present+ Cristiano_Aguzzi, Jan_Romann, Tomoaki_Mizushima 11:10:21 TOPIC: Previous minutes 11:10:31 -> August-1 -> https://www.w3.org/2022/08/01-wot-script-minutes.html 11:11:11 JKRhb has joined #wot-script 11:12:10 dp: Any objections to approving the minutes? 11:12:14 Minutes are approved 11:12:26 topic: Quick Updates 11:12:38 subtopic: Cancellations in August 11:12:57 dp: As mentioned in main call, we will have two cancellation in august 11:13:20 i/Any ob/scribenick: JKRhb/ 11:13:27 ... no call on August 15 and 29, with one call inbetween on August 22 11:14:30 ca: Can't join on the 22nd 11:14:56 dp: We can have a short call at this date 11:15:06 subtopic: Next charter topics 11:15:38 dp: When it comes to rechartering, we need to think about the document type (note, rec, ...) 11:15:46 q+ 11:15:53 ... dedicated issue in the scripting repo 11:16:03 ... my feeling is that we should go for the Note track 11:16:23 zk: I added a comment to the issue 11:16:37 ... how about moving the Scripting API to the community group 11:17:06 ... could be a proper specification with faster progress 11:17:32 present+ Ege_Korkan 11:17:40 ... potential topics are management API, credentials, conformance classes 11:17:47 ack zk 11:18:03 Ege has joined #wot-script 11:18:10 ... not in favor of splitting up the document 11:18:32 dp: Note track can also include normative statements now 11:18:41 ... would make it easy to switch tracks 11:18:56 q+ 11:19:03 ... community group would not get any "official" W3C support 11:19:25 ca: Integration into Community Group would also require a rechartering 11:19:50 zk: What is the difference between this WoT CG and the one by Ben? 11:20:00 q? 11:20:03 ca: The other one focuses on protocols 11:20:16 zk: Scripting API would not fit into that one 11:20:38 kaz: I'm okay with a decision by the whole group 11:21:05 ... we need to be careful with the document type decision 11:21:20 ... and include the decision in the minutes 11:21:52 s/a decision/any decision/ 11:22:03 s/we need to/however, we need to/ 11:22:06 ... we should be clear about the pros and cons of each document type 11:22:37 s/with the document type decision/about the definition of the document types/ 11:23:14 dp: There other potential topics, one concerns the support for the EXI profile 11:23:59 ... there are aspects (like the queryactions op type) which are not supported by the Scripting API, therefore they are not supported by node-wot 11:24:04 q? 11:24:08 q- 11:24:15 ... making it difficult for developers to support it 11:24:20 ... we should keep this in mind 11:24:28 topic: PRs 11:24:49 subtopic: PR #423 11:25:14 dp: Created by Cristiano before the call 11:25:44 ca: What I did here was removing the eventHandler 11:25:58 ... developers should not have to implement it 11:26:11 ... already included in node-wot, however 11:27:13 ca: Minor change regarding the potential event sources, the mentioning of the underlying platform has been removed 11:28:04 zk: Asked a question in the PR if the EventHandler is needed 11:28:15 ... if it is not needed then we can remove it 11:28:35 s/in the PR/in issue 408/ 11:29:44 ca: The use case for it is not there yet 11:29:51 zk: Then I support removing it 11:30:10 dp: I agree, if there is no use case for having an EventHandler, then we don't need it 11:30:18 ... overcomplicates things 11:30:39 ca: We could merge the PR but leave the issue open for potential further discussion 11:31:04 zk: We should record the discussion in the issue, justifying the PR 11:31:44 ... the respective comment in the PR should also be reformulated in a concise way 11:32:03 dp: (Adds a comment to issue #408) 11:35:16 ca: There is an open comment regarding a "void" data payload 11:35:45 ... could be reformulated, didn't use undefined because it is a Javascript concept 11:36:03 dp: Couldn't we say "no payload"? 11:36:22 ca: Some protocols have payloads with no content 11:36:39 ... we could avoid using void, however 11:36:49 dp: We will wait for the improvement of the PR 11:36:55 ... will also check the rest 11:37:23 subtopic: PR #424 11:37:43 ca: Marked it as draft for now just to inform you about a potential issue 11:37:59 ... I noticed a number of missing references in the document 11:38:10 ... for example, in the ExposedThing section 11:39:04 ... there we now have a correct reference that was not working before 11:39:22 ... this was fixed by adding brackets 11:40:25 ... this not causes the problem that there are missing descriptions for internal slots 11:40:42 s/this not/this now/ 11:41:26 ... will be included in the PR later 11:42:02 ... internal slots now also offer context menus listing references 11:42:20 ... should also be done for the ExposedThing 11:43:40 dp: There is a difference in the node-wot implementation regarding activeSubscriptions and activeObservations in node-wot at the moment 11:44:58 zk: PR looks good, I already approved it. The remaining internal slots should be mentioned as well 11:45:11 ca: Problem is that we have complex internal slots 11:45:27 ... does it work to add these to the list? 11:45:41 zk: As they are dynamic, we should remove them 11:46:41 dp: There is also currently an error regarding activeSubscriptions and activeObservations, as they are not part of the ConsumedThing but of the Event/Property 11:46:59 s/dp: There is also/ca: There is also/ 11:48:01 zk: There might also be a different solution to internal slots. Question would be if we can describe the algorithms without internal slots 11:48:37 ca: They make describing the algorithms easier. An alternative would be to use a map instead of a set here 11:48:44 topic: Issues 11:48:54 subtopic: Issue #417 11:48:58 rrsagent, make log public 11:49:02 rrsagent, draft minutes 11:49:02 I have made the request to generate https://www.w3.org/2022/08/08-wot-script-minutes.html kaz 11:49:20 dp: This issue is by Ege 11:49:51 ... there was some discussion about what is actually meant by the issue 11:50:22 ek: Current API currently reads values twice 11:50:43 i|As mentioned in main|-> https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Cancellations_and_Schedule_Updates Cancellations on the WoT main wiki| 11:51:28 q+ 11:51:57 i|When it comes|-> https://github.com/w3c/wot/issues/978 wot issue 978 - Goals and Deliverable Discussion for WoT WG 2023 Proposed Charter| 11:53:15 i|Created by C|-> https://github.com/w3c/wot-scripting-api/pull/423 PR 423 - Remove eventHandler| 11:53:54 i|Marked it as draft|-> https://github.com/w3c/wot-scripting-api/pull/424 PR 424 - Fix internal slots| 11:54:03 rrsagent, draft minutes 11:54:03 I have made the request to generate https://www.w3.org/2022/08/08-wot-script-minutes.html kaz 11:55:06 i|This issue is by|-> https://github.com/w3c/wot-scripting-api/issues/417 Issue 417 - emitPropertyChange does not take low-level event apis into account| 11:55:10 zk: With the current API, another read should not be necessary 11:55:33 q+ 11:58:28 ek: I can give a more detailed example in code 11:58:41 q+ 11:58:55 ... the current API design implies that you need to read again on a property change 11:58:57 ack c 11:58:59 q+ 12:00:07 kaz: Regarding this issue, I would like to hear from Ege some more detail about the expected use case and scenario, rather than the data model and API 12:00:24 ... it should be clarified what should be done in certain situations 12:01:08 ek: My use case is that I have, for example, a sensor or a robot arm, which changes state and would then emit a property change (rather than an event) 12:01:36 ... question is how to deal with such changes and how to define with low-level changes 12:02:25 q+ 12:03:17 ca: I am starting to see the use case, question is how much complexity is introduced by the current API and how to keep consistency between reading and observing property 12:03:42 zk: I wonder if this is about implementation optimization or API design 12:03:53 q+ 12:04:01 ... implementation feedback is important, however, we need to take feedback into account 12:04:02 ack kaz 12:04:06 ack cris 12:04:09 ek: I will provide a code example 12:04:09 ack zkis 12:04:13 ack Ege 12:04:20 ... an exposer thing implementation 12:04:45 .... with well-defined or safe behavior 12:05:05 ... accessing the property twice should slow down the implementation only slightly, though 12:06:10 ca: Returning the cached value would not trigger read twice 12:06:22 dp: Let's move on based on Ege's example 12:06:57 ... next call will be on the 15th 12:07:04 [adjourned] 12:07:08 ack k 12:07:17 rrsagent, draft minutes 12:07:18 I have made the request to generate https://www.w3.org/2022/08/08-wot-script-minutes.html kaz 12:07:25 s/on the 15th/on the 22nd/ 12:07:49 rrsagent, draft minutes 12:07:49 I have made the request to generate https://www.w3.org/2022/08/08-wot-script-minutes.html kaz 12:09:23 zkis has joined #wot-script 14:34:09 Zakim has left #wot-script 14:44:15 zkis has joined #wot-script 16:17:55 kaz has joined #wot-script 17:45:54 kaz has joined #wot-script 18:50:18 kaz has joined #wot-script 19:16:56 zkis has joined #wot-script