10:04:22 <RRSAgent> RRSAgent has joined #wot-script
10:04:27 <RRSAgent> logging to https://www.w3.org/2025/02/05-wot-script-irc
10:04:32 <kaz> meeting: WoT Scripting API
10:05:10 <kaz> chair: Cristiano
10:05:40 <kaz> present+ Kaz_Ashimura, Cristiano_Augzzi, Zoltan_Kis, Daniel_Peintner, Tomoaki_Mizushima
10:06:06 <zkis> scribenick: zkis
10:06:20 <zkis> Topic: Past Minutes
10:06:43 <Mizushima> Mizushima has joined #wot-script
10:07:00 <kaz> -> https://www.w3.org/2025/01/22-wot-script-minutes.html Jan-22
10:07:31 <zkis> Minutes approved.
10:07:34 <kaz> agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#February_5%2C_2025
10:07:38 <zkis> Topic: PRs
10:07:55 <zkis> Subtopic: PR 561 Extended return type of invokeAction()
10:07:59 <cris> https://github.com/w3c/wot-scripting-api/pull/561
10:09:34 <zkis> CR: the current starting point is to include the extensions to a single object.
10:10:17 <dape> q+
10:10:18 <zkis> CR: ZK argued for extending the InteractionOutput object (summarizing the comment).
10:10:38 <kaz> s/ZK/Zoltan/
10:11:04 <zkis> CR: agree with the message, but we lack information due to TD 2.0 gaps
10:11:34 <zkis> ... not clear what assumptions can we make
10:12:24 <zkis> ... the proposal is to keep the feature low in the abstraction layer, i.e. add it to the ConsumedThing interface
10:12:33 <cris> q?
10:12:35 <zkis> q+
10:12:38 <zkis> ack dape
10:13:11 <zkis> DP: the solution is vague because it's underspecified
10:13:22 <zkis> ... we should acknowledge this
10:14:46 <zkis> ... so it's in the application domain how to deal with this
10:15:45 <zkis> CA: The discussion is relevant also for other op's
10:16:21 <kaz> q+
10:16:21 <zkis> ... in theory we support all operations
10:16:26 <zkis> ack zkis
10:18:49 <zkis> ZK: it's a syntactic thing where we expose canceling actions
10:19:16 <zkis> ... if canceling is not supported, it can return an error (if it's known it cannot cancel); otherwise it's a problem
10:19:32 <zkis> CA: we already have a use case for controling actions
10:20:10 <zkis> q?
10:20:12 <dape> q+ to future
10:20:13 <zkis> ack kaz
10:20:32 <zkis> Kaz: agree with Zoltan, think for several options
10:20:54 <zkis> ... we can publish a Note that is in sync with the TD spec
10:21:08 <zkis> q?
10:21:16 <dape> ack dape
10:21:16 <Zakim> dape, you wanted to future
10:21:18 <zkis> ack dape
10:21:40 <zkis> DP: let's assume TD 2.0 will break compatibility
10:21:51 <JKRhb> JKRhb has joined #wot-script
10:21:56 <zkis> ... Scripting might also have breaking changes
10:22:02 <kaz> s/several options/several possible patterns for the actions and return types using several use cases./
10:22:25 <kaz> s/we ca publish/regarding publication of the Scripting API Note, we can publish/
10:22:38 <zkis> DP: we should do our best for current TD spec, then might do changes
10:22:44 <zkis> q?
10:22:47 <zkis> q+
10:22:55 <zkis> ack zkis
10:22:59 <kaz> s/the TD spec/the TD spec, and describe additional considerations as Editor's Notes./
10:23:15 <kaz> rrsagent, make log public
10:23:19 <kaz> rrsagent, draft minutes
10:23:20 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:23:40 <zkis> ZK: the current design will not break, it's just extension
10:24:02 <kaz> present+ Jan_Romann
10:24:12 <zkis> CA: ok, but it's not a problem if we break since TD 2.0 is assumed to break things
10:24:53 <kaz> s|s/we ca publish/regarding publication of the Scripting API Note, we can publish/||
10:25:01 <zkis> CA: the web usually is backward compatible
10:25:09 <kaz> s/we can publish a Note/regarding publication of the Scripting API Note, we can publish/
10:25:12 <kaz> rrsagent, draft minutes
10:25:14 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:25:31 <zkis> q?
10:25:57 <zkis> Jan: we can proceed with the object approach
10:26:53 <dape> q+
10:27:59 <zkis> CA: the TD use cases are supported also by extending ConsumedThing, but we'd need to identify the actions (payloads), or URI variables
10:28:18 <zkis> ... both designs have ways to pass information in the headers
10:28:26 <zkis> ack dape
10:29:22 <zkis> DP: are you saying we should add options to cancel()?
10:29:31 <zkis> CA: yes
10:30:39 <kaz> rrsagent, draft minutes
10:30:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:31:19 <zkis> CP: we can do what we do with e.g. write: options or URI variables
10:32:03 <zkis> DP: what is the cancel endpoint is different?
10:32:12 <zkis> CA: that is likely a form index
10:33:52 <zkis> CA: similar to canceling subscriptions
10:34:15 <zkis> ZK: so when there is no args to cancel, impls try to figure out, otherwise they take args from the app
10:34:21 <kaz> i|are you|-> https://github.com/w3c/wot-scripting-api/pull/561/files#diff-3fbbd64bda915440e7c332856e7b46e5c9ac6d95af738b428e34c5f00e6e5b5a PR 561 - diff for index.d.ts
10:34:23 <kaz> rrsagent, draft minutes
10:34:24 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:35:27 <zkis> ZK: ok, this doesn't change the API shape, only parameters
10:35:35 <zkis> CA: what is later this is deprecated?
10:35:51 <zkis> ZK: then we add prose to say we'll ignore arguments from now on
10:36:13 <dape> q+
10:36:14 <zkis> Jan: we need implementation experience, will provide
10:36:21 <zkis> ack dape
10:36:56 <zkis> DP: the status() call returns what?
10:37:08 <zkis> CA: a streaming object, since we don't know yet its format
10:37:27 <zkis> ... to be decided
10:37:38 <zkis> DP: and cancel() is like stopping a subscription?
10:37:41 <zkis> CA: yes
10:37:49 <kaz> q+
10:38:09 <zkis> DP: so these signatures are compatible
10:38:31 <zkis> CA: we can return InteractionOutput, for future flexibility
10:39:36 <zkis> ZK: cancel cannot be guaranteed, but it can register user intent for canceling
10:40:04 <zkis> DP: we should expose all errors we get
10:40:07 <zkis> ZK: yes
10:40:13 <zkis> q?
10:41:14 <zkis> Kaz: there are bigger issues than just return type
10:41:41 <zkis> ... we should decide what to include in the Note
10:41:44 <dape> q+
10:42:21 <kaz> ack k
10:42:27 <zkis> Kaz: we need use cases on how to map the returned streaming object
10:42:55 <zkis> CA: we cannot make assumptions yet on action lifecycle data
10:43:13 <zkis> ... nor about payloads in query and cancel actions
10:43:21 <kaz> s/in the Note/in the Note itself, and then clarify what to be done for the future Note inline with TD 2.0.
10:43:22 <zkis> ... we can only invoke the ops of cancel and query
10:43:25 <kaz> rrsagent, draft minutes
10:43:27 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:43:50 <kaz> s/streaming object/streaming object for the 2nd point above./
10:43:53 <zkis> ZK: I am not sure we want an error property
10:44:02 <kaz> rrsagent, draft minutes
10:44:04 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:44:11 <zkis> DP: yes, and also replace status() with query()
10:44:11 <dape> ack dape
10:45:00 <kaz> s/CP:/CA:/
10:45:04 <kaz> rrsagent, draft minutes
10:45:06 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:45:32 <zkis> ZK: but the TD spec will have to define the result types of query()
10:45:35 <kaz> s/CR:/CA:/g
10:45:37 <kaz> rrsagent, draft minutes
10:45:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:45:45 <zkis> CA: yes, we can use InteractionOutput for now
10:45:49 <zkis> q?
10:46:31 <zkis> Topic: publication schedule
10:46:41 <zkis> CA: how should we do release approach
10:47:11 <zkis> CA: or should we stop development for TD1.1?
10:48:59 <dape> q+
10:49:35 <zkis> ZK: we already have the mechanisms in place
10:49:44 <zkis> q?
10:50:01 <zkis> DP: agree with that, but the current link is generic
10:51:23 <kaz> q+
10:51:37 <zkis> ack dape
10:52:16 <zkis> Kaz: all versions are identified by the date of the URL
10:52:31 <kaz> -> https://www.w3.org/standards/history/wot-thing-description10/ e.g., TD history 1.0
10:53:48 <dape> ack dape
10:54:00 <kaz> s/all versions/we don't need to think about the publication URLs today, but the latest URL will be used by the latest version document./
10:54:53 <kaz> s/version document. are identified/version document. then the older version documents will be identified/
10:54:56 <kaz> rrsagent, draft minutes
10:54:58 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:55:31 <kaz> s/topic: publication/topic: Publication/
10:55:52 <kaz> s/we don't/We don't/
10:55:58 <kaz> s/then the o/Then the o/
10:56:00 <kaz> rrsagent, draft minutes
10:56:01 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:56:30 <kaz> s/Topic: publication/topic: Publication/
10:56:32 <kaz> rrsagent, draft minutes
10:56:33 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:56:58 <zkis> ZK: Scripting should be able to handle Things with both TD1.1 and TD 2.0 specs
10:57:09 <kaz> s/date of the URL/dated URL (and the history area)./
10:57:09 <zkis> ... so we need a single Scripting API to handle both
10:57:10 <kaz> rrsagent, draft minutes
10:57:11 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
10:57:35 <zkis> CA: time is up, call adjourned
10:57:39 <kaz> rrsagent, draft minutes
10:57:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/05-wot-script-minutes.html kaz
12:29:11 <JKRhb> JKRhb has joined #wot-script
13:05:28 <mahda> mahda has joined #wot-script
13:13:18 <Zakim> Zakim has left #wot-script
14:48:07 <JKRhb> JKRhb has joined #wot-script
15:06:42 <JKRhb> JKRhb has joined #wot-script
15:47:02 <JKRhb> JKRhb has joined #wot-script