Meeting minutes
Minutes
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/
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/
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
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/
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]