- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 20 Sep 2021 17:49:36 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2021/08/23-wot-script-minutes.html
also as text below.
Thanks a lot for taking the minutes, Cristiano!
Kazuyuki
---
[1]W3C
[1] https://www.w3.org/
WoT Scripting API
23 August 2021
[2]Agenda. [3]IRC log.
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Scripting_API_WebConf#23_August_2021
[3] https://www.w3.org/2021/08/23-wot-script-irc
Attendees
Present
Cristiano_Aguzzi, Daniel_Peintner, Kaz_Ashimura,
Tomoaki_Mizushima, Zoltan_Kis
Regrets
-
Chair
Daniel
Scribe
cris, kaz
Contents
1. [4]previous minutes
2. [5]Quick updates
3. [6]Open PRs
1. [7]PR 331
4. [8]issues
1. [9]propose closing issues
Meeting minutes
previous minutes
<kaz> [10]Aug-9
[10] https://www.w3.org/2021/08/09-wot-script-minutes.html
Daniel: we talked about TypeScript definitions types, now
merged
… we moved issue 193 to other task forces
… also touched propose closing issues but we'll finish the
discussion today
… minutes approved?
… ok
Quick updates
Daniel: we should keep in mind publication plan
… Semptember? we don't have any pressure
Open PRs
PR 331
Daniel: minor pr
<dape> docs: add readme about TS files and process,
[11]https://github.com/w3c/wot-scripting-api/pull/331
[11] https://github.com/w3c/wot-scripting-api/pull/331
Daniel: it's about the latest changes in typescript folder
… there's no readme under typescript folder
… the PR adds the two readmes
Cristiano: good to go :)
Daniel: should we wait for merge it?
Zoltan: don't need to wait
Daniel: ok merging
… no more open PRs
issues
<dape> Propose Closing Issues, [12]https://github.com/w3c/
wot-scripting-api/
issues?q=is%3Aissue+is%3Aopen+label%3A%22propose+closing%22
[12] https://github.com/w3c/wot-scripting-api/issues?q=is:issue+is:open+label:"propose+closing"
propose closing issues
<kaz> [13]Issue 107 - Very high frequency updates
[13] https://github.com/w3c/wot-scripting-api/issues/107
Daniel: issue 107 is very old
… it seems like the idea is to close the issue and move the
discussion to TD
Cristiano: I don't think keeping it open would benefit anyone.
let's move to TD task force
Zoltan: I'd move to TD task force too, but it doesn't hurt to
keep it open
… also we should think about how this affect our API in any way
Daniel: it might change HOW the users use our API
Zoltan: we might need to add some parameter to
InteractionOption
Daniel: when I said HOW I meant that people might decide to use
Polling instead of observing if they can't handle event
frequency
Kaz: Why don't we label the issue with "discussion with TD"
… and remove next iteration, it is quite vague
… maybe next charter? or out of scope
Zoltan: it is an optional change... deep down is about
implementation
Daniel: it might be really complex and you will get not too
much in return
Cristiano: I had the same feeling
Zoltan: we need to check the api desing to handle control flow
transparently.
… we have streams now
… maybe we are missing the client hint to tell the other side
how much it can handle
… I'd put this facts on the issue
… we need to solve the problem
Kaz: We can close the issue for the scripting api itself and
move it to use case or profile
Zoltan: dave implementation is an use case
Kaz: not really a product
… I usually refer to business implementation
… echonet is an example
… Philips Hue another one
… research base implementation might be still fine but is it
well connected ?
<zkis> [14]https://opentelemetry.io/docs/
[14] https://opentelemetry.io/docs/
Zoltan: we can learn from open API for telemetry
Daniel: is it from intel?
Zoltan: no, but we can keep in mind its design
Daniel: closing or not, we have still to keep it track of it
<zkis> [15]https://open-telemetry.github.io/opentelemetry-js/
[15] https://open-telemetry.github.io/opentelemetry-js/
Kaz: "next iteration" is vague... we failed to clarify and
close the issue in a timely manner.
Daniel: it is a place holder to look for improvements
… but I see your point
Zoltan: the trivial answer is to use streams
Cristiano: yes exactly
Kaz: for example, with the MEIG, we are looking for further
collaboration with WoT
… but we don't have a good use case description yet
Kaz: we should clarify actual use cases about how to handle
streaming videos for WoT, e.g., streaming data, data cue and
time synchronization.
Cristiano: about next iteration I agree that it is a little bit
vague and do not incentive people into discussion
Daniel: ok, then remove "propose closing" and "for next
iteration" labels
Cristiano: why don't we directly ask people to verify if the
current api cover the feature described in the issue
Zoltan: ok
Daniel: ok commented
Daniel: I'd remove "next iteration" labels where it make sense
… for example issue 274 it was not really deferred but just an
optional feature
Cristiano: suggestion: why don't we change next iteration to
something more precise? next charter?
Daniel: I'm not sure that we are part of regular chartering
process
Kaz: My proposal is to just put "enhancement" everywhere is
possible, for example where we don't know the timing.
Cristiano: not sure, if it is actually equivalent
Kaz: since we approaching the end of this charter we should
reach a consensus: either enachement or close.
… or clearly state which one should be close in this period
frame.
… do we have any priority.
Zoltan: I don't have strong opinion. We have bigger problems,
like discovery
Kaz: "next iteration" implied that the issues should have been
closed by the end of this period when those issues were
generated.
Zoltan: I would keep them open, just use better label
Cristiano: what about some legend on the labels?
Zoltan: should be fine
… also I think our time together should be more focused on
features rather than house keeping
Daniel: ok. I'd create a table for labels
… PR will be available soon
adjourned
Minutes manually created (not a transcript), formatted by
[16]scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).
[16] https://w3c.github.io/scribe2/scribedoc.html
Received on Monday, 20 September 2021 08:49:41 UTC