– DRAFT –
WoT Scripting API

Minutes

Dec-5

Dec-19

Cristiano: (goes through both the minutes quickly)

Kaz: note that we should say "co-moderator" instead of "co-chair"

Cristiano: that's true

Kaz: just fixed

Cristiano: Zoltan's name within Dec-5 minutes should be also fixed

Kaz: fixed

Publication

Issue 433 - New publication within current charter?

Cristiano: the draft is not ready yet
… can we still publish an updated draft?

Kaz: yes, you can
… note our current WG Charter has been extended till the end of July

Daniel: yes, we should publish an updated draft
… we can deal with the issues for the next Charter later

Cristiano: ok
… we're planning to polish the current version draft focusing on th Discovery API and bug fixes

wot PR 1043 - proposal for scripting - next charter

Daniel: proposed several points on Scripting for the next WG Charter
… but after the discussion, got that we don't need to too much details into the Charter.

<cris_> Draft WG Charter

Cristiano: Daniel's proposed changes have not been applied to the draft Charter above

Kaz: Daniel's PR was made for the MD files
… so probably we should make another PR to update the draft Charter HTML

Daniel: ok. will do

PRs

PR 381

feat: reintroduce "local" discovery method

Cristiano: (goes through the proposed changes)

Jan: maybe we can close this

Cristiano: maybe should create separate issues?

Jan: yeah

Cristiano: any objections?

(none)

Jan: will work on the relevant issues

Issues

Issue 417

<cris_> w3c/wot-scripting-api#417

Issue 417 - emitPropertyChange does not take low-level event apis into account

Cristiano: long standing issue

<zkis> ZK: I made a summary in this comment: w3c/wot-scripting-api#417 (comment)

Kaz: clarify our own initial expectation of the level of APIs
… and Zoltan has been doing so on this issue
… we don't/can't need to handle all the possible interconnection pattern
… that should be handled by Binding Templates

<Mizushima> +1 kaz

Zoltan: the question here is not a problem with the Scripting API itself
… need broader discussion around Architecture, etc.
… need to clarify which required features came from which use case as well

Cristiano: yeah
… need more evaluation in terms of use cases and TD spec

Daniel: wondering where the use case somewhat similar
… if big values are problematic, that would applied to events too

Zoltan: will create an issue on Architecture
… on the other hand, for now, we could agree possible fix for WebIDL

partial interface ExposedThing {
    Promise<undefined> emitPropertyChange(DOMString name);
}

=>

partial interface ExposedThing {
    Promise<undefined> emitPropertyChange(DOMString name,
        optional InteractionInput value);

Cristiano: ok
… another issue on interaction with devices?

Zoltan: yeah
… should be handled separately

Kaz: that's my point as well

Cristiano: would close this issue itself, and discuss the new API problem in another dedicated issue
… think the initial problem is already addressed

Zoltan's comments

Cristiano's comments

proposed API definition:

partial interface ExposedThing {
    Promise<undefined> emitPropertyChange(DOMString name, InteractionInput value);
}

Cristiano: I'm fine with having the "optional"to support user-defined values
… but we should warn the implementers about the shortcoming in this issue

(kept open)

Issue 409

<cris_> Issue 409 - Harmonize the exposing process

Cristiano: (goes through the issue)

Daniel: we should move this update
… should try to improve the situation

<zkis> Questions: w3c/wot-scripting-api#409 (comment)

Cristiano: wait for improvement before moving on with the changes

Zoltan: probably we need some experiments
… without duplicating things

Question 1: should ExposedThing extend ProducedThing, or should the
  latter be an internal slot to the former (composition)?

  My take: an internal slot would be more convenient and maybe more
  clear as well (no confusions about fake inheritance).

Question 2: Should expose() also start servicing requests right away, or
  should it just be a factory method to initialize the service for the
  exposed Thing, and the script would also have additional control on
  when to actually start the service, i.e. ExposedThing would have a
  start() method, therefore likely a stop() method, too. If a script
  also wants to release the resources as well, we could provide a
  shutdown() (or destroy()) method.

Question 3: could we add handlers as dictionary attributes (callbacks)
  to ProducedThing? Or keep the current methods for adding callbacks?

  My take: currently the algorithms for the handlers-adding methods are
  quite trivial, and they mainly add the callbacks as internal slots, so
  they could be replaced by attributes as well. However, the algorithms
  are more flexible than defining getters/setters. So I suggest we keep
  the methods for now.

Question 4: do we really need to get the partial TD out of
  ProducedThing? It's kind of confusing at this point. The script
  already knows all information that would contain. Testing could be
  done on internal slots.

  My take: we don't need it. We can add it when we realize it's needed.
  :)

Question 5: should we have options to the expose() method? If yes, what?

  My take: we can add it when we realize what is needed. I included it
  in the Web IDL below, but needs not be specified.

Daniel: we should finish what we can do now
… and continue further discussion after that

Cristiano: wouldn't hurt to start reviewing the proposals
… the review process can be shared for both the stable draft and the new proposals
… maybe need another publication for the new proposals, though

AOB

Mizushima: there are still many issues remaining
… should clarify our policy about how to deal with them

Cristiano: let's talk about that next time

Kaz: for that purpose, we should clarify version management as well
… which features to go for the current version of Scripting API which is compatible with TD 1.1
… and which to go for the next version which would be compatible with TD 2.0

Cristiano: yes

[adjourned]