[Scripting] minutes - 3 February 2020

available at:
  https://www.w3.org/2020/02/03-wot-minutes.html

also as text below.

Thanks a lot for taking the minutes, Zoltan!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                             WoT-Scripting

03 Feb 2020

Attendees

   Present
          Kaz_Ashimura, Daniel_Peintner, Michael_McCool,
          Tomoaki_Mizushima, Zoltan_kis

   Regrets

   Chair
          Zoltan

   Scribe
          zkis

Contents

     * [2]Topics
         1. [3]Minutes from the previous call
         2. [4]https://github.com/w3c/wot-scripting-api/issues/200
         3. [5]https://github.com/w3c/wot-scripting-api/issues/199
         4. [6]https://github.com/w3c/wot-scripting-api/issues/192
         5. [7]https://github.com/w3c/wot-scripting-api/issues/190
         6. [8]https://github.com/w3c/wot-scripting-api/issues/107
     * [9]Summary of Action Items
     * [10]Summary of Resolutions
     __________________________________________________________

   Past minutes:
   [11]https://www.w3.org/2020/01/27-wot-minutes.html

     [11] https://www.w3.org/2020/01/27-wot-minutes.html

   <scribe> scribenick: zkis

Minutes from the previous call

   Discussing past minutes, about the order of priority if
   multiple Forms are present

   Daniel: we should raise awareness of the TD TF about this
   ... the issue is broader than just Scripting
   ... it's not related to the past minutes themselves, though

   <scribe> ACTION: DP create an issue for Forms priority
   discussion in TD

   Zoltan: can we approve the past minutes? Yes.

   Past minutes approved.

[12]https://github.com/w3c/wot-scripting-api/issues/200

     [12] https://github.com/w3c/wot-scripting-api/issues/200

   Discussing error reporting mechanisms.

   Zoltan: is it possible to map protocol errors to ECMAScript
   errors, or should we have separate mechanism for reporting

   Daniel: we should be careful not creating too many error types

   Zoltan: do we have mainly CoAP and HTTP bindings?

   Daniel: in node-wot we have more

   Zoltan: the TD doesn't really describe errors

   Daniel: right
   ... the reason Ege raised this was because node-wot returned
   generic errors too often and it was hard figuring out the
   underlying error conditions
   ... without looking at the actual error message
   ... Ege is working on the testing tool
   ... we need to look at each method in the Scripting API and
   figure more meaningful error reporting

   Zoltan: we cannot expose all error information in Scripting
   because of fingerprinting

   Daniel: at least with HTTP errors it would be nice to share
   detailed error information
   ... at least the error codes

   Zoltan: could apps tell which bindings (Forms) are being used
   by implementations?

   Daniel: right, they cannot tell and cannot affect currently
   ... other than we currently pick the first available
   ... (in node-wot)
   ... so yes, if we get a failure, we don't know which bindings
   were used
   ... to start with, we can use better errors, and then we could
   expose which bindings were used

   Zoltan: since we don't have too many protocols, we could
   include an informative table on how we use errors
   ... this concludes the list of issues that needed discussion
   before we update the spec

[13]https://github.com/w3c/wot-scripting-api/issues/199

     [13] https://github.com/w3c/wot-scripting-api/issues/199

   Daniel: there should be an error if a write handler is
   registered for non-writeable property

   Zoltan: but this is a way the app can implement the enforcement
   policy
   ... or do we want to deprive apps from specifying that and
   should the runtime enforce the TD policies?

   Daniel: so it would be just a Note that implementations (of
   ExposedThing) are actually the ones that implement the policy

[14]https://github.com/w3c/wot-scripting-api/issues/192

     [14] https://github.com/w3c/wot-scripting-api/issues/192

   Zoltan: when we create ExposedThing, do implementations
   generate a TD?

   Daniel: apps should provide the TD strings themselves
   ... using the produce() method

   Zoltan: but then the "annotations" should be part of the TD
   (and standardized with the TD)

   Daniel: right

[15]https://github.com/w3c/wot-scripting-api/issues/190

     [15] https://github.com/w3c/wot-scripting-api/issues/190

   Zoltan: do we need a generic FW like
   [16]https://github.com/web-platform-tests/wpt/ ?

     [16] https://github.com/web-platform-tests/wpt/

   <dape> TUM has [17]https://github.com/tum-esi/testbench

     [17] https://github.com/tum-esi/testbench

   Zoltan: so it's under work now

[18]https://github.com/w3c/wot-scripting-api/issues/107

     [18] https://github.com/w3c/wot-scripting-api/issues/107

   Daniel: we could use Websockets for very high frequency updates

   <McCool> mccool: I will have to drop soon to prep for security
   call

   McCool: I hope we could leverage we already have
   ... we need to gather more exact requirements

   Zoltan: also client-side policies, e.g. how much data can it
   consume how often
   ... are restrictions imposed by JavaScript etc

   McCool: depending on abstraction level, we could get JavaScript
   away
   ... just used for setting up
   ... we should check similar problems on other places.

   Adjourned.

Summary of Action Items

   [NEW] ACTION: DP create an issue for Forms priority discussion
   in TD

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [19]scribe.perl version 1.154 ([20]CVS log)
    $Date: 2020/02/11 08:13:17 $

     [19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [20] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 11 February 2020 08:13:47 UTC