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

[Scripting][DRAFT] minutes - 21 September 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 28 Sep 2020 18:20:17 +0900
Message-ID: <87mu1ai7fy.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/09/21-wot-minutes.html

also as text below.

Thanks a lot for taking the notes, Zoltan!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                           WoT Scripting API

21 Sep 2020

Attendees

   Present
          Kaz_Ashimura, Cristiano_Aguzzi, Daniel_Peintner,
          Tomoaki_Mizushima, Zoltan_Kis

   Regrets

   Chair
          Zoltan

   Scribe
          zkis

Contents

     * [2]Topics
         1. [3]Past minutes
         2. [4]TypeScript definitions
         3. [5]Publication schedule
         4. [6]PR 264,
            https://github.com/w3c/wot-scripting-api/pull/264
     * [7]Summary of Action Items
     * [8]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: zkis

Past minutes

   <kaz> [9]Sep-14

      [9] https://www.w3.org/2020/09/14-wot-minutes.html

   Zoltan: any objections for accepting the past minutes?

   none

   Past minutes accepted.

TypeScript definitions

   Cristiano: some questions, the problem is that we are defining
   the Scripting API in 2 different ways
   ... one is defining a global object
   ... other times we accept a namespace that is not global
   ... the problem is this doesn't work as it's not recognized as
   a namespace
   ... we need to change the TypeScript definitions

   Zoltan: and also the Scripting API?

   <kaz> [10]index.d.ts

     [10] https://github.com/w3c/wot-scripting-api/tree/master/typescript

   Cristiano: we should find a way to make the TS definition work
   in the browser as well

   Daniel: we had a discussion on node-wot and all proposals had
   some problem

   Zoltan: do we have a Scripting issue for this?

   [11]https://github.com/w3c/wot-scripting-api/issues/215

     [11] https://github.com/w3c/wot-scripting-api/issues/215

   Zoltan: relevant opinion:
   [12]https://github.com/w3c/wot-scripting-api/issues/3#issuecomm
   ent-283746764
   ... so, 1) the root object should not be constructable
   ... 2) if it has no state, then a namespace is OK
   ... 3) if it has state, has to be a global object
   ... we also have conformance classes, we can group along those

     [12] https://github.com/w3c/wot-scripting-api/issues/3#issuecomment-283746764

   Daniel: there was a lot of discussion since the workarounds had
   issues

   Cristiano: the recommended way is not to define a global
   variable, but use a namespace
   ... since making a global variable will duplicate the functions

   Zoltan: we should also keep in mind future functionality like
   management interface, that could be a new conformance class,
   namespace or global object

   Cristiano: if we export as namespace WoT, it worked
   ... we don't have a global variable in node-wot
   ... we could have 2 TS definition files
   ... or if we have one TS definition, we need to explain this vs
   modules/namespace/global object

   Daniel: we'd like that everyone could use the same TS
   definition

   Cristiano: the problem is that it works if we create a runtime,
   but doesn't work from inside a runtime

   Zoltan: subnamespaces?

   Cristiano: not supported in TS

   Daniel: if we just declare the namespace WoT, would it work?

   Cristiano: we don't have a module then
   ... so we cannot import it as it was a module

   Daniel: could the implementation manage the module vs
   implementation transparently so that code like WoT.consume()
   works?

   Cristiano: for short term, I could make a PR to test with
   node-wot and trying to make it work

   Daniel: we could have a playground for testing these ideas on
   npm
   ... we could have a snapshot to play with, in a branch

   Zoltan: if there are effects on the Scripting API, please
   update the issue

Publication schedule

   Zoltan: we need to clear the open issues

   Daniel: we probably cannot close all issues

   Kaz: publication for FPWD/FPWGN does not have to be perfect

   Zoltan: FPWD or a Note?

   Kaz: First Public WG Note if we change the name and the
   shortname URL
   ... we could also change the name to e.g. Scripting API 1.1

   Zoltan: I would vote for just updating the current publication

   Daniel: agree, no jumps just evolutionary change

   Kaz: there will be several difficult points all the time
   ... the suggestion is to go ahead and publish

   Daniel: yes, and there will be remaining issues
   ... IMHO all Web IDL related issues should go in
   ... for instance the current PR (#264), but improving the text
   could be done later
   ... so I would not postpone it long, because it needs to be
   implemented and tested

   Zoltan: how long we need for publication

   Kaz: a week of group review and addressing feedback

   Zoltan: it means we need to complete all changes by the group
   call on Wednesday

   Kaz: got it, but note that there will be no group calls during
   F2F. also probably it would be difficult for people to review
   the updated draft during the PlugFest next week too

PR 264, [13]https://github.com/w3c/wot-scripting-api/pull/264

     [13] https://github.com/w3c/wot-scripting-api/pull/264

   Zoltan: there is a pretty new API to check for idioms,
   [14]https://wicg.github.io/cookie-store/

     [14] https://wicg.github.io/cookie-store/

   Daniel: have a question for multiple consecutive optional args

   Zoltan: should work

   Cristiano: I agree, it should work

   Zoltan: we need to check it for TypeScript
   ... dictionary and function are nullable so it should be OK
   ... we also want to create an issue for defining PropertyMap as
   record instead

   Daniel: the Web IDL change looks good

   Cristiano: looks okay, are we ok to create the new pattern with
   Subscription

   Zoltan: yes, it is ok. Also check the Cookie Store API for when
   to use an event and when a subscription function

   Cristiano: question about unsubscribe Form

   Zoltan: raised that issue in the TD TF and asked for help in
   the group call
   ... now we have a proposed algorithm, but could be improved

   Cristiano: until when can this PR be commented on?

   Zoltan: I would make a constraint for the TD to defined
   unsubscribe Forms together with subscribe Forms

   Cristiano: would be good design but would break the TD spec
   ... we need to discuss this in the TD
   ... we should issue a separate issue for that

   Zoltan: right

   Daniel: like a generic "how to find an unsubscribe Form for a
   subscribe Form"

   <scribe> ACTION: ZK to file an issue at the TD spec

   adjourned

Summary of Action Items

   [NEW] ACTION: ZK to file an issue at the TD spec

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [15]scribe.perl version ([16]CVS log)
    $Date: 2020/09/28 08:02:59 $

     [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 28 September 2020 09:20:24 UTC

This archive was generated by hypermail 2.4.0 : Monday, 28 September 2020 09:20:26 UTC