W3C

- DRAFT -

WoT Scripting API

31 Aug 2020

Attendees

Present
Zoltan_Kis, Kaz_Ashimura, Daniel_Peintner, Cristiano_Aguzzi
Regrets
Tomoaki_Mizushima
Chair
Zoltan
Scribe
zkis

Contents


Approving past 2 minutes

<kaz> Aug-17

<kaz> Aug-24

<scribe> scribe: zkis

Zoltan: updated the readme, and for the older docs, if not maintained, we could move them to the archive

<scribe> ACTION: ZK updates the rationale.md

Aug 17 minutes approved.

Zoltan: can we do validation in constructor?

Cristiano: yes, it can be done
... also, in expose() we need to check if the runtime supports the forms defined by the TD

Zoltan: makes sense

Daniel: node-wot picks one Form and throws away the rest

Zoltan: to my understanding, the Forms are in OR relationship, so at least one Form should pick

Daniel: and we throw away all other Forms
... node-wot doesn't use URLs for instance in HTTP Forms, they are pruned from the start

Cristiano: but we should support hints

Zoltan: definitely we need to update the expose() algorithm

Daniel: it's difficult to support hints

Cristiano: this is true for Forms perhaps, but what about security
... e.g. if we want OAuth and that is not supported

Zoltan: security schemes define if they are OR, AND, OneOf type - scripting algorithms should follow that semantics

<scribe> ACTION: CA file an issue security scheme

<scribe> ACTION: ZK update the expose() algorithm (with a tracking issue)

Aug 24 minutes approved

Issue 253 https://github.com/w3c/wot-scripting-api/issues/253 closed by PR

<kaz> closed

Issue 241 https://github.com/w3c/wot-scripting-api/issues/241

Zoltan: interaction is better understood by developers, we can put a note explaining the relationship with affordance

Daniel: TD spec uses affordance

Cristiano: interaction is more clear indeed, but there is the argument to be in line with other specs

Daniel: making a comment in the issue

Issue 237 https://github.com/w3c/wot-scripting-api/issues/237

API discussion for exposing errors

Cristiano: would add another proposal
... using the subscribed as a Promise()

Zoltan: we need a status for subscription and this could be merged with that

Daniel: we could have a callback also for that

Zoltan: we need a property, since the state is triggered by the error

Cristiano: the apps wants to make choices based on the error, so it's fine to expose

Daniel: would prefer providing the callbacks in the function signature

Zoltan: and we stay with the Promise

Cristiano: maybe passing callbacks in an object would be better perhaps

call adjourned

Summary of Action Items

[NEW] ACTION: CA file an issue security scheme
[NEW] ACTION: ZK update the expose() algorithm (with a tracking issue)
[NEW] ACTION: ZK updates the rationale.md
 

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/09/07 06:46:09 $