W3C home > Mailing lists > Public > public-wot-wg@w3.org > June 2020

[Scripting] minutes - 25 May 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 08 Jun 2020 10:33:41 +0900
Message-ID: <87v9k2wdca.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.




      [1] http://www.w3.org/

                               - DRAFT -

                             WoT Scripting

25 May 2020


          Kaz_Ashimura, Cristiano_Aguzzi, Daniel_Peintner,
          Mihcael_McCool, Zoltan_Kis, Tomoaki_Mizushima





     * [2]Topics
         1. [3]Approving past minutes
         2. [4]PR
         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

   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

   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
   ... 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/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/

   Zoltan: or we could expose readers like in the File API:
   ... 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

   Zoltan: so the app needs to figure out if there was a
   ... 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

   Cristiano: we could also do it like the impl checks for the
   ... 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

   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

   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

TD contentType vs 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

   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

This archive was generated by hypermail 2.4.0 : Monday, 8 June 2020 01:33:00 UTC