- 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