<scribe> scribe: zkis

Past minutes

<kaz> Sep-14

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> index.d.ts

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?

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

Zoltan: relevant opinion: https://github.com/w3c/wot-scripting-api/issues/3#issuecomment-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

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, https://github.com/w3c/wot-scripting-api/pull/264

Zoltan: there is a pretty new API to check for idioms, 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