Meeting minutes
Minutes
Daniel: (goes through the minutes)
Daniel: approved and will be published
PRs
PR 332
PR 332 - fix: links *new* typescript folder
Daniel: the PR fixes a small issue with links
Label Table, 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> GitHub labels for wot-scripting-api repo
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, 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> wot-scripting - 3. Conformance
Daniel: asking ZK to take a look at the issue and eventually rename it
TypeScript - Type DataSchemaValue circularly references itself, 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, https://
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> see also the Issue 200 - Error Handling
Zoltan: we already have that in the algorithms
Daniel: we still miss e.g. NotFoundError
<kaz> e.g., 7.4 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