- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 08 Jun 2020 10:33:41 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/05/25-wot-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Scripting
25 May 2020
Attendees
Present
Kaz_Ashimura, Cristiano_Aguzzi, Daniel_Peintner,
Mihcael_McCool, Zoltan_Kis, Tomoaki_Mizushima
Regrets
Chair
Zoltan
Scribe
zkis
Contents
* [2]Topics
1. [3]Approving past minutes
2. [4]PR
https://github.com/w3c/wot-scripting-api/pull/209
3. [5]TD contentType vs strings
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<kaz> Meeting: WoT Scripting
Approving past minutes
[8]https://www.w3.org/2020/05/18-wot-minutes.html
[8] 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 [9]https://github.com/w3c/wot-scripting-api/pull/209
[9] https://github.com/w3c/wot-scripting-api/pull/209
Zoltan: a pretty big change last week
... also, discussion in
[10]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
[10] https://github.com/w3c/wot-scripting-api/issues/201
Cristiano: explains reasoning for using a function
... here is a gist with some experimentation
[11]https://gist.github.com/relu91/05928793fbed8e95b1db0035c903
8bf7
[11] 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
[12]https://wicg.github.io/serial/
[12] https://wicg.github.io/serial/
Zoltan: or we could expose readers like in the File API:
[13]https://w3c.github.io/FileAPI/#dfn-filereader
... the stream interface is quite cumbersome compared to a
value() function (or property)
[13] https://w3c.github.io/FileAPI/#dfn-filereader
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>
[14]https://gist.github.com/relu91/05928793fbed8e95b1db0035c903
8bf7#strings
[14] 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: [15]https://w3c.github.io/FileAPI/#dfn-filereader
... so it would look like File reader with multiple functions
for reading.
... or the Body mixin: [16]https://fetch.spec.whatwg.org/#body
[15] https://w3c.github.io/FileAPI/#dfn-filereader
[16] 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]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [17]scribe.perl version ([18]CVS log)
$Date: 2020/05/25 13:58:25 $
[17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[18] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 8 June 2020 01:32:59 UTC