- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 20 Sep 2021 18:00:41 +0900
- To: public-wot-wg@w3.org
available at: https://www.w3.org/2021/08/30-wot-script-minutes.html also as text below. Thanks a lot for taking the minutes, Zoltan! Kazuyuki --- [1]W3C [1] https://www.w3.org/ WoT Scripting API 30 August 2021 [2]Agenda. [3]IRC log. [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#30_August_2021 [3] https://www.w3.org/2021/08/30-wot-script-irc Attendees Present Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis Regrets - Chair Daniel Scribe kaz, zkis Contents 1. [4]Minutes 2. [5]PRs 1. [6]PR 332 2. [7]Label Table, https://github.com/w3c/ wot-scripting-api/pull/333 3. [8]issues discussion 1. [9]Separate ExposedThing API, https://github.com/w3c/ wot-scripting-api/issues/303 2. [10]TypeScript - Type DataSchemaValue circularly references itself, https://github.com/w3c/ wot-scripting-api/issues/301 3. [11]error handling Meeting minutes Minutes [12]Aug-23 [12] https://www.w3.org/2021/08/23-wot-script-minutes.html Daniel: (goes through the minutes) Daniel: approved and will be published PRs PR 332 [13]PR 332 - fix: links *new* typescript folder [13] https://github.com/w3c/wot-scripting-api/pull/332 Daniel: the PR fixes a small issue with links Label Table, [14]https://github.com/w3c/wot-scripting-api/pull/333 [14] https://github.com/w3c/wot-scripting-api/pull/333 Daniel: updates the labels we use in github … and documents it Daniel: there are a lot of unused labels (without any issues using them), propose to remove them. Zoltan: makes sense Cristiano: I would keep some labels, like bug and duplicate, they might be still useful … I've seen them in other repositories as well Daniel: we don't use them right now Cristiano: I think that is not a problem with such generic labels Daniel: should we also include these in the Readme? Cristiano: yes, why not Zoltan: a table in a readme needs maintaining, syncing with the real labels Daniel: we could also link to the github generated list Zoltan: and include descriptions there Kaz: I'm fine with keeping several unused labels … we should be consistent across the whole WG how to use labels … propose to discuss this in the main call … it's fine to remove unused labels, and to use github descriptions to explain the labels <kaz> [15]GitHub labels for wot-scripting-api repo [15] https://github.com/w3c/wot-scripting-api/issues/labels Daniel: OK, things are converging, we can do this way Cristiano: +1 for discussing within the WG Daniel: so I will modify the PR to just link to the label list issues discussion Daniel: we can talk about discovery and TD … the discussion about writeProperty() was discussed in the TD TF, but many calls were canceled and we should wait on that … any preferred topics? Separate ExposedThing API, [16]https://github.com/w3c/ wot-scripting-api/issues/303 [16] https://github.com/w3c/wot-scripting-api/issues/303 Cristiano: trying to implement the separate ExposedThing API in node-wot Cristiano: do we have consensus about this change? Daniel: it's a bit scattered over issues Cristiano: should I experiment in node-wot about this? Zoltan: I think yes Daniel: we dropped ExposedThing extending ConsumedThing Zoltan: and they are in separate conformance classes already Cristiano: so the issue is something more, right? Zoltan: it was mainly to separate ExposedThing to a different spec (client-server API separation) Cristiano: so it's about split implementation, and maybe split spec? Daniel: I am not sure this is where we should head towards … we do have 3 conformance classes already … splitting the doc doesn't seem necessary <kaz> [17]wot-scripting - 3. Conformance [17] https://w3c.github.io/wot-scripting-api/#conformance Daniel: asking ZK to take a look at the issue and eventually rename it TypeScript - Type DataSchemaValue circularly references itself, [18]https://github.com/w3c/wot-scripting-api/issues/301 [18] https://github.com/w3c/wot-scripting-api/issues/301 Daniel: checking to close/remove it … it's solved already, so removing it error handling <dape> Error Handling, [19]https://github.com/w3c/ wot-scripting-api/issues/200 [19] https://github.com/w3c/wot-scripting-api/issues/200 Daniel: this is a bit unclear, also raised in the WoT Profile TF … it's not easy to detect which binding the issue appeared in Zoltan: should WoT abstract not only the positive protocol outcomes, but also the negative ones? Daniel: in some cases it would be good to know about the bindings error info … we already have some way to select a form index Zoltan: it has privacy reasons to hide that information from web pages Daniel: Ege provided an error mapping list, but I think it gets very nasty with more protocols added … so what should we do with this issue? Zoltan: this is a runtime issue, we could use log levels Cristiano: log levels make it inconvenient to use from application logic … it would be better to standardize the list of errors … if we can do mapping, it will be the best option … but even if not, developers should be able to do something about the errors from the proper code … not only for debugging, but for alternative business logic Zoltan: let's leave this open then, it's important because it may affect the API shape Daniel: we could have the mapping, and for each method list the errors <kaz> [20]see also the Issue 200 - Error Handling [20] https://github.com/w3c/wot-scripting-api/issues/200 Zoltan: we already have that in the algorithms Daniel: we still miss e.g. NotFoundError <kaz> [21]e.g., 7.4 The readProperty() method [21] https://w3c.github.io/wot-scripting-api/#the-readproperty-method Zoltan: then let's make a separate issue about that Daniel: OK, creating an issue Cristiano: we should re-read the spec, looking for things that can go sideways … not sure we are covering all the use cases Daniel: we do use NotFoundError in node-wot Daniel: also, we may use multiple security levels, global level and form level Cristiano: right now we just have global security, e.g. you can either read or not a property Daniel: time out, we continue in the issues adjourned Minutes manually created (not a transcript), formatted by [22]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC). [22] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 20 September 2021 09:00:46 UTC