W3C

- DRAFT -

WoT Scripting

04 May 2020

Attendees

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

Contents


<scribe> scribe: zkis

approving previous minutes

Past minutes: https://www.w3.org/2020/04/27-wot-minutes.html

Minutes approved.

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

Daniel: Cristiano is working to implement OAuth2 and filed this issue.

<Ege> https://github.com/owncloud/oauth2/wiki/OAuth-code-Flow-Sequence-Diagram

Zoltan: need to check if it is enough to have Promises

Daniel: use might get a popup before the Promise resolves

Zoltan: that is fine, but in a headless system you should be provisioned and not need a popup

Ege: quick authorize can happen through scripting, but in other cases there is a human involved

Zoltan: how is a human involved? popup?

Ege: yes

Zoltan: even then the Promise would be on hold, so the API works with or without a human in the loop
... the question is, do we need to change the API, but so far I don't see the need
... will comment on the issue

pull request https://github.com/w3c/wot-scripting-api/pull/209

Daniel: suggested https://github.com/w3c/wot-scripting-api/pull/209#issuecomment-619905410

Zoltan: the proposal of moving properties of InteractionData to InteractionOptions for writes works for me, actually I like it
... showing example from Web NFC, writing takes more possibilities and will switch on developer provided type

Daniel: I see an issue that we have different InteractionOptions for writing than for reading
... I would prefer TypeScript approach

Zoltan: but this is an accepted pattern, it should be fine

Daniel: for one, would NOT like if we moved stuff in InteractionOptions for writing
... then, would like to have InteractionData both for reading and writing

Zoltan: is there a TypeScript related issue or an esthetic concern?

Daniel: both

Zoltan: implementation should still determine the type from value
... in the current PR, it doesn't break the API and handles the extra information

Daniel: I would prefer the explicit InteractionData structure (only) on both reading and writing
... how other APIs handle "any"?

Zoltan: there was some discussion that a typedef is preferred, need to check
... so let's write examples in all the styles

Ege: that sounds good

Daniel: we could actually merge the PR and then experiment

Ege: how could we ask developers about preferences?

Zoltan: we'd need to reach out and ask specific people

Daniel: open a separate issue with this and ping some people

Zoltan: maybe we can use issue 201: https://github.com/w3c/wot-scripting-api/issues/201
... and I can ask TAG members for advice

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

Zoltan: we need a convention for simply exposing strings

Daniel: in most cases the implementation knows the encoding (in closed environments)
... also, ASCII only strings could always be exposed

Zoltan: right
... but we need to specify these in the algorithms

Daniel: did we get any comments about language or encoding?
... enumerations should work language independent

Zoltan: right, but e.g. error messages won't
... apps may want to ask a certain language

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/05/07 14:32:15 $