12:04:42 <RRSAgent> RRSAgent has joined #wot-script
12:04:46 <RRSAgent> logging to https://www.w3.org/2023/01/30-wot-script-irc
12:06:22 <kaz> meeting: WoT Scripting API
12:06:45 <kaz> present+ Kaz_Ashimura, Cristiano_Aguzzi, Tomoaki_Mizushima
12:08:49 <kaz> scribenick: kaz
12:08:54 <kaz> topic: Minutes
12:09:04 <dape> dape has joined #wot-script
12:09:35 <kaz> -> https://www.w3.org/2022/12/05-wot-script-minutes.html Dec-5
12:09:57 <kaz> present+ Zoltan_Kis
12:11:13 <kaz> -> https://www.w3.org/2022/12/19-wot-script-minutes.html Dec-19
12:11:24 <kaz> ca: (goes through both the minutes quickly)
12:11:55 <kaz> q+
12:11:58 <zkis> zkis has joined #wot-script
12:14:56 <kaz> kaz: note that we should say "co-moderator" instead of "co-chair"
12:15:01 <kaz> ca: that's true
12:15:07 <kaz> kaz: just fixed
12:15:30 <kaz> ca: Zoltan's name within Dec-5 minutes should be also fixed
12:15:33 <kaz> kaz: fixed
12:15:44 <kaz> present+ Daniel_Peintner
12:15:53 <kaz> present+ Jan_Romann
12:16:05 <kaz> topic: Publication
12:16:37 <kaz> ca: the draft is not ready yet
12:16:45 <kaz> ... can we still publish an updated draft?
12:16:48 <dape> q+
12:16:49 <kaz> kaz: yes, you can
12:16:51 <kaz> ack k
12:17:08 <kaz> ... note our current WG Charter has been extended till the end of July
12:17:32 <kaz> dp: yes, we should publish an updated draft
12:17:53 <kaz> ... we can deal with the issues for the next Charter later
12:18:22 <dape> ack dape
12:18:45 <kaz> ca: ok
12:18:51 <zkis> zkis has joined #wot-script
12:19:08 <kaz> ... we're planning to polish the current version draft focusing on th Discovery API and bug fixes
12:20:22 <kaz> q?
12:21:25 <kaz> i|the draft is|-> https://github.com/w3c/wot-scripting-api/issues/433 Issue 433 - New publication within current charter?|
12:22:16 <kaz> -> https://github.com/w3c/wot/pull/1043 wot PR 1043 - proposal for scripting - next charter
12:22:34 <kaz> dp: proposed several points on Scripting for the next WG Charter
12:22:39 <cris_> https://github.com/w3c/wot/blob/main/charters/wot-wg-2023-draft.html
12:23:21 <kaz> i/draft/... but after the discussion, got that we don't need to too much details into the Charter./
12:23:38 <kaz> s/https/-> https/
12:25:01 <kaz> s/html/html Draft WG Charter/
12:25:45 <cris_> https://github.com/w3c/wot-scripting-api/pull/381
12:25:49 <kaz> ca: Daniel's proposed changes have not been applied to the draft Charter above
12:26:07 <kaz> kaz: Daniel's PR was made for the MD files
12:26:24 <kaz> ... so probably we should make another PR to update the draft Charter HTML
12:26:29 <kaz> dp: ok. will do
12:26:45 <kaz> s|https://github.com/w3c/wot-scripting-api/pull/381||
12:26:50 <kaz> topic: PRs
12:26:55 <kaz> subtopic: PR 381
12:27:18 <kaz> -> https://github.com/w3c/wot-scripting-api/pull/381 feat: reintroduce "local" discovery method
12:27:33 <kaz> ca: (goes through the proposed changes)
12:27:57 <kaz> jr: maybe we can close this
12:27:59 <kaz> q?
12:28:14 <kaz> ca: maybe should create separate issues?
12:28:21 <kaz> jr: yeah
12:28:35 <kaz> ca: any objections?
12:29:06 <kaz> (none)
12:29:51 <kaz> jr: will work on the relevant issues
12:30:14 <kaz> topic: Issues
12:30:24 <kaz> subtopic: Issue 417
12:30:32 <cris_> https://github.com/w3c/wot-scripting-api/issues/417
12:30:35 <kaz> -> https://github.com/w3c/wot-scripting-api/issues/417 Issue 417 - emitPropertyChange does not take low-level event apis into account
12:30:45 <kaz> ca: long standing issue
12:32:13 <kaz> q+
12:33:35 <zkis> ZK: I made a summary in this comment: https://github.com/w3c/wot-scripting-api/issues/417#issuecomment-1400305844
12:36:02 <kaz> kaz: clarify our own initial expectation of the level of APIs
12:36:19 <kaz> ... and Zoltan has been doing so on this issue
12:36:45 <kaz> ... we don't need to handle all the possible interconnection
12:36:52 <kaz> ... that should be handled by Binding Templates
12:37:13 <dape> q+
12:37:17 <kaz> ack k
12:37:22 <Mizushima> +1 kaz
12:37:37 <kaz> zk: the question here is not a problem with the Scripting API itself
12:37:53 <kaz> ... need broader discussion around Architecture, etc.
12:38:37 <kaz> s|don't|don't/can't|
12:38:52 <kaz> s/interconnection/interconnection pattern/
12:39:43 <kaz> ... need to clarify which required features came from which use case as well
12:40:05 <kaz> ca: yeah
12:40:36 <kaz> ... need more evaluation in terms of use cases and TD spec
12:40:37 <kaz> q?
12:41:09 <kaz> dp: wondering where the use case somewhat similar
12:41:35 <zkis> q+
12:42:26 <kaz> ... if big values are problematic, that would applied to events too
12:42:30 <kaz> ack d
12:42:32 <kaz> ack z
12:42:32 <dape> ack dape
12:43:13 <kaz> zk: will create an issue on Architecture
12:43:43 <kaz> ... on the other hand, for now, we could agree possible fix for WebIDL
12:43:50 <cris_> q?
12:44:05 <kaz> [[
12:44:06 <kaz> partial interface ExposedThing {
12:44:07 <kaz>     Promise<undefined> emitPropertyChange(DOMString name);
12:44:07 <kaz> }
12:44:07 <kaz> ]]
12:44:09 <kaz> to:
12:44:10 <kaz> [[
12:44:19 <kaz> partial interface ExposedThing {
12:44:20 <kaz>     Promise<undefined> emitPropertyChange(DOMString name,
12:44:20 <kaz>         optional InteractionInput value);
12:44:20 <kaz> ]]
12:45:07 <kaz> ca: ok
12:45:31 <kaz> ... another issue on interaction with devices?
12:45:35 <kaz> zk: yeah
12:45:46 <kaz> ... should be handled separately
12:45:55 <kaz> kaz: that's my point as well
12:46:30 <kaz> ca: would close this issue itself, and discuss the new API problem in another dedicated issue
12:46:38 <kaz> chair: Cristiano
12:47:04 <kaz> ... think the initial problem is already addressed
12:49:33 <kaz> -> https://github.com/w3c/wot-scripting-api/issues/417#issuecomment-1408562300 Cristiano's comments
12:50:21 <kaz> i|https|-> https://github.com/w3c/wot-scripting-api/issues/417#issuecomment-1408558134 Zoltan's comments
12:50:51 <kaz> proposed API definition:
12:50:52 <kaz> [[
12:50:53 <kaz> partial interface ExposedThing {
12:50:53 <kaz>     Promise<undefined> emitPropertyChange(DOMString name, InteractionInput value);
12:50:55 <kaz> }
12:50:57 <kaz> ]]
12:51:24 <kaz> ca: I'm fine with having the "optional"to support user-defined values
12:51:58 <kaz> .... but we should warn the implementers about the shortcoming in this issue
12:52:09 <kaz> (kept open)
12:52:18 <kaz> sutopic: Issue 409
12:52:20 <cris_> https://github.com/w3c/wot-scripting-api/issues/409
12:52:24 <kaz> s/sutopic/subtopic
12:53:00 <kaz> s/https/-> https/
12:53:09 <kaz> s/409/409 Issue 409 - Harmonize the exposing process/
12:53:16 <kaz> ca: (goes through the issue)
12:53:51 <kaz> dp: we should move this update
12:54:06 <kaz> ... should try to improve the situation
12:54:09 <zkis> Questions: https://github.com/w3c/wot-scripting-api/issues/409#issuecomment-1337895782
12:54:47 <kaz> ca: wait before moving on with the changes
12:54:57 <kaz> s/wait/wait for improvement/
12:55:44 <kaz> zk: probably we need some experiments
12:55:57 <kaz> ... without duplicating things
12:56:23 <kaz> [[
12:56:24 <kaz> Question 1: should ExposedThing extend ProducedThing, or should the latter be an internal slot to the former (composition)?
12:56:24 <kaz> My take: an internal slot would be more convenient and maybe more clear as well (no confusions about fake inheritance).
12:56:24 <kaz> 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.
12:56:27 <kaz> ]]
12:56:59 <kaz> [[
12:56:59 <kaz> Question 3: could we add handlers as dictionary attributes (callbacks) to ProducedThing? Or keep the current methods for adding callbacks?
12:57:00 <kaz> 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.
12:57:00 <kaz> 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.
12:57:02 <kaz> My take: we don't need it. We can add it when we realize it's needed. :)
12:57:04 <kaz> Question 5: should we have options to the expose() method? If yes, what?
12:57:06 <kaz> 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.
12:57:09 <kaz> ]]
12:57:19 <kaz> dp: we should finish what we can do now
12:57:32 <kaz> ... and continue further discussion after that
12:58:47 <kaz> ca: wouldn't hurt to start reviewing the proposals
12:59:13 <kaz> ... the review process can be shared for both the stable draft and the new proposals
12:59:34 <kaz> ... maybe need another publication for the new proposals, though
12:59:39 <kaz> [adjourned]
12:59:44 <kaz> rrsagent, make log public
12:59:47 <kaz> rrsagent, draft minutes
12:59:49 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/30-wot-script-minutes.html kaz
13:00:02 <kaz> s/[adjourned]//
13:00:07 <kaz> topic: AOB
13:00:19 <kaz> mizu: there are still many issues remaining
13:00:30 <kaz> ... should clarify our policy about how to deal with them
13:01:06 <kaz> ca: let's talk about that next time
13:01:20 <kaz> q+
13:01:58 <kaz> kaz: for that purpose, we should clarify version management as well
13:02:19 <kaz> ... which features to go for the current version of Scripting API which is compatible with TD 1.1
13:02:32 <kaz> ... and which to go for the next version which would be compatible with TD 2.0
13:02:38 <kaz> ca: yes
13:02:45 <kaz> [adjourned]
13:02:53 <kaz> rrsagent, draft minutes
13:02:54 <RRSAgent> I have made the request to generate https://www.w3.org/2023/01/30-wot-script-minutes.html kaz