<kaz> Meeting: WoT Scripting

Approving past minutes

https://www.w3.org/2020/05/18-wot-minutes.html

Minutes approved.

<scribe> scribe: zkis

McCool: we should discuss the Oauth2 topic

Daniel: next week there is public holiday

McCool: let's do the Oauth2 discussion in the Security call today

Daniel: ok

Cristiano: ok

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

Zoltan: a pretty big change last week
... also, discussion in https://github.com/w3c/wot-scripting-api/issues/201
... added ReadableStream and modified the algorithms
... what is open is whether value is a function or property

Cristiano: explains reasoning for using a function
... here is a gist with some experimentation

https://gist.github.com/relu91/05928793fbed8e95b1db0035c9038bf7

Zoltan: handling 2 Promises is more complex IMHO than parsing right away the value

Cristiano: the app might want to read the stream itself
... the impl should not interfere with that

Zoltan: if value is function, after calling that and it fails, is the stream still readable?

Cristiano: the read part of the stream is wasted

Zoltan: what about reading the stream, trying to part, and create a second stream to expose to the app?
... would it be a waste?

Cristiano: yes, it would be a waste

Daniel: like with the formIndex, apps could give a hint if they want to runtime to parse or to expose the stream

Zoltan: we have the option to expose a stream only like in the Serial API

https://wicg.github.io/serial/

Zoltan: or we could expose readers like in the File API: https://w3c.github.io/FileAPI/#dfn-filereader
... the stream interface is quite cumbersome compared to a value() function (or property)

Cristiano: we should provide a way to choose low level or value() function

Zoltan: what happens if the value() function fails?

Cristiano: we could do that we check if there is DataSchema, if yes, we expose the high level, otherwise the stream

Zoltan: that sounds good, except need to check what happens if value() fails anyway

Cristiano: that would mean an error also with the stream
... we would expose both value() and the stream and let the app choose

Zoltan: so the app needs to figure out if there was a DataSchema
... which is a bit more complex

Cristiano: yes, apps need to check that, but that is a small price for the freedom to choose the way of reading

Zoltan: still a problem since it's a quirky way to check for DataSchema

Cristiano: we could also do it like the impl checks for the DataSchema
... then parse the data from the network interface
... misunderstanding
... impl gets the Response object, then the client calls the value() function
... the runtime checks if DataSchema is defined
... if not, then returns an error
... if defined, it would parse and return the value
... so if value() fails, app checks if stream is not consumed, then parse the stream
... if consumed, needs to repeat the read operation

Zoltan: that sounds fairly consistent

Daniel: we put too much stress on apps
... we need too much boilerplate code even for the majority of cases

Zoltan: apps could use value() the same way as before
... just that now they have an extra option

Cristiano: I agree we should maintain it as simple as possible

Zoltan: should we have value() return Promise?

Cristiano: yes, since that would separate parsing completely

<Zakim> dape, you wanted to changes to readAll/readMultiple

Daniel: wondering what would be the consequence to readAll and readMultiple

Zoltan: it should not be much difference from app side, it's the same interface that is exposed, - but the read happened via a single network operation

Cristiano: I also think it should work since we are deferring just the parsing and not the network interaction

Zoltan: I think we are good to go with this, will make a commit today

TD contentType vs strings

<dape> https://gist.github.com/relu91/05928793fbed8e95b1db0035c9038bf7#strings

Cristiano: whether contentType is used at higher level or in the Forms

McCool: for backwards compatibility we need to keep the old way
... we might need a rule that the Form overrides the top one

Cristiano: actually JSON Schema says that you can specify a string with encoding
... inside the file we have string with given content type

Zoltan: this should be fine, the image will be encoded base64 and exposed as string; the app will decode the base64 and then the image

Cristiano: I got a comment from Ege, that we could use JSON Schema properties even if it's not defined in the TD (?)

Zoltan: we could figure out WHEN would it be a problem

McCool: yes, still an important use case to figure out

Cristiano: browsers support base64 image source
... another example is image with no dataschema, the best would be to expose DataView or the stream
... sorry that is another proposal, to ADD DataView for that case

Zoltan: can we get that from the stream?

Cristiano: a new function blob() for instance

Zoltan: https://w3c.github.io/FileAPI/#dfn-filereader
... so it would look like File reader with multiple functions for reading.
... or the Body mixin: https://fetch.spec.whatwg.org/#body

<McCool> (going to have to drop; security call; ttyl)

Cristiano and Zoltan discussed to keep the InteractionData and adapt from Blob as needed

<kaz> [adjourned]