WoT Scripting API

14 Sep 2020


Kaz_Ashimura, Zoltan_Kis, Cristiano_Aguzzi, Tomoaki_Mizushima, Daniel_Peintner


<scribe> Agenda: https://github.com/w3c/wot-scripting-api/pulls, https://github.com/w3c/wot-scripting-api/issues

<scribe> scribe: zkis

past minutes


Past minutes approved.


PR 263, https://github.com/w3c/wot-scripting-api/pull/263

Daniel: will review today

PR 260 https://github.com/w3c/wot-scripting-api/pull/260

Looks good, merged.

PR 244, https://github.com/w3c/wot-scripting-api/pull/259

Zoltan: this has a problem, mentioned in the PR

Daniel: we may init lazily, not in consume()

Zoltan: when to init then?

Daniel: when interactions are called, they could be init'd then

Cristiano: yes, that could work
... what we need to decide if we fail early, or during the interactions (if they are not set up correctly, or there is an error)
... I have no problem with consume() being a bit different than constructor

Zoltan: consume() could fail early and constructor could use lazy init

Cristiano: this could work, need to think

Daniel: we should not fail for something implementations can correct

Cristiano: that's a valid point as well

Daniel: and this is also valid on exposed things as well as consumed things
... so we should fail only when things cannot work

Cristiano: similarly, for security, we should be flexible, e.g. if one of the schemes work, it should be fine
... we could lazily push error

Zoltan: I agree, also because the nature of these comms is async, over various protocols so we cannot guarantee to fail early
... TD validation is only syntactic, not functional

PR262: https://github.com/w3c/wot-scripting-api/pull/262

Zoltan: there is a question about global consistency of Forms (e.g. every interaction has a CoAP form)

Daniel: we should be flexible here

Cristiano: we need the flexibility
... we have an open issue about ops and also about default values
... TD issue 957

Zoltan: please put any ideas for the expose() algorithm in the PR

Daniel: again the vote goes for flexibility

Cristiano: we should not expose something we cannot handle

Zoltan: right, we could remove the constraint

Daniel: yes, a TD is not necessarily by this runtime

Zoltan: we can leave it generic - on the other hand that step is very complex and we have no good description of it
... but for now I will remove the sentence

Cristiano: architecturally we cannot enforce form existence or syntax

PR 261, https://github.com/w3c/wot-scripting-api/pull/261

Zoltan: trivial change, done what the issue proposed

Cristiano: right

Daniel: looks good


Ege's review

Zoltan: did we cover all issues raised from the review
... I need to check that.

<scribe> ACTION: ZK to check if there are issues not handled from Ege's review

issue 258, https://github.com/w3c/wot-scripting-api/issues/258

Zoltan: in the light said today, what should we do for this issue

Cristiano: right, we need to rething that
... will comment later

issue 242, https://github.com/w3c/wot-scripting-api/issues/242

Daniel: here as well we should apply the flexibility argument

Zoltan: if the TD designer specified these constraints, they should be respected

Cristiano: agree with the need of checking
... at least with the convenience methods
... of the value() function

Daniel: had a similar problem in the past, sometimes schemas are too refined and restricted; often the implementations cannot be that rigurous

Cristiano: we should check what JSON Schema does

Zoltan: let's do that

next call

Cristiano: propose an agenda to talk about TypeScript definitions

Daniel: we said we should have a spec before the plugfest, but we should at least solve subscribe/unsubscribe


Summary of Action Items

[NEW] ACTION: ZK to check if there are issues not handled from Ege's review

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/21 14:12:49 $