<scribe> scribenick: zkis

approving previous minutes

<kaz> https://www.w3.org/2020/04/20-wot-minutes.html

Zoltan: any issues with that?

no objections, minutes approved

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

Zoltan: DP mentioned talking with people about API design

Daniel: yes, people preferred a symmetric API, but it's a compromise
... there was going back and forth
... regarding the issue discussion, ZK's latest proposal is good since it extends the API unbroken with new functionality
... so the "any" sometimes could be InteractionData
... agreed with Ege this is a good start to explore this idea in code, without changing the API
... so it's good solution for the moment and in the simple case there is no overhead
... one can provide a simple integer for instance

Zoltan: yes, that was the idea
... and it also forced me to define the algorithms for bindings, which we have not done yet
... but it turned out to be good
... we can change later to InteractioData only, or keep it this way

Daniel: maybe we could merge the PR but create a new issue that captures the discussion

<kaz> Issue 201

<kaz> PR 209

<kaz> section 6.16 ConsumedThing Examples (within the PR 209)

Zoltan: there is another possible solution; we always assume simple data and we define a "content exception" that would be handled via InteractionData.

Daniel: wondering how would that work in code but the separation might be useful
... we could also plainly fail and then in another call recover with InteractionData

Zoltan: that's a good idea

Daniel: but not sure that's a scenario what people would use

Zoltan: what about passing an app option to read to tell implementation how to present the data?

Daniel: that makes sense

Zoltan: another thing is, should we have options for language and encoding for reads?
... that would allow presenting a string that has encoding and language in a simple way (now it is only possible via InteractionData)

Daniel: there was a language negotiation thing in the TD
... currently the implementation would take the locale settings as default

Zoltan: it would be a scripting specific SW option, making app's life easier
... also, doing it in implementations is safer
... we have another option: always use InteractionData but put there the simple value as a property

<kaz> 7. The InteractionData interface (within PR 209)

Zoltan: will make a comment to illustrate the idea

Daniel: will discuss that with Ege and Sebastian

Zoltan: we need to experiment by writing code examples and see what works best

WASI/WASM

Daniel: node.js now supports WASM/WASI
... from v14.0.0

<dape> https://nodejs.org/api/wasi.html

Zoltan: WASI doesn't yet support network operations

MM: the use case is to use something compiled, to run on a Scripting runtime

Zoltan: TypeScript is supported in WASM
... the problem is not every system call is implemented in WASI

<McCool> https://wicg.github.io/web-transport/

adjourned