- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 07 Sep 2020 15:52:31 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/08/24-wot-minutes.html
also as text below.
Thanks a lot for taking the minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Scripting API
24 Aug 2020
Attendees
Present
Kaz_Ashimura, Cristiano_Aguzzi, Daniel_Peintner,
Ege_Korkan, Jakob_Weigand, Tomoaki_Mizushima, Zoltan_Kis
Regrets
Chair
Zoltan
Scribe
zkis
Contents
* [2]Topics
1. [3]Guest
2. [4]PRs
3. [5]PR239,
https://github.com/w3c/wot-scripting-api/pull/239
4. [6]issue # 237
5. [7]issue #244
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribe: zkis
Guest
Jacob Weigand is a guest from TUM today, and aware of the W3C
Patent Policy
PRs
PR 246, [10]https://github.com/w3c/wot-scripting-api/pull/246
[10] https://github.com/w3c/wot-scripting-api/pull/246
Zoltan: w3cid to be completed, please add a commit
Cristiano: will do
PR239, [11]https://github.com/w3c/wot-scripting-api/pull/239
[11] https://github.com/w3c/wot-scripting-api/pull/239
Cristiano: went through the doc for corrections
... a major modification is adding the writeAllProperties()
method
... also, changed an algorithm name
Zoltan: I agree with the algorithm name
Daniel: a comment about writeAll: would not spend too much time
on that since it's going to go away
... in the TD spec
Zoltan: do we know what is in the writeAll Form, since the
algorithm might depend on that?
... what about moving the writeAll commit to a branch and wait
for the TD spec?
Cristiano: we could do that
Daniel: we could do everything with writeMultiple
Cristiano: though that it was writeMultiple will go away
Daniel: maybe we will need writeAll in the future, but I also
think we should wait with adding writeAll
Cristiano: we could add an editor's note why don't we have it
Zoltan: right
Daniel: and say we could use just writeMultiple
Zoltan: ok, so these PRs will get changes and then merges
issue # 237
<dape> [12]https://github.com/w3c/wot-scripting-api/issues/237
[12] https://github.com/w3c/wot-scripting-api/issues/237
<inserted> [13]Scripting API draft - D. Full Web IDL
[13] https://w3c.github.io/wot-scripting-api/#idl-index
Jacob: Ege asked to make a demo with the problem
... MQTT cannot communicate an error in the subscription
... when the server is dropping, the Scripting API does not
provide an error in the subscription
... the next subscribe request should fail
... same with longpoll
... there is also a race condition
Zoltan: we have 2 options: a separate object for a subscription
with an error event, or put the error event on ConsumedThing
Cristiano: would prefer the first
Daniel: we could have a generic error (call?)
... or an object that can point to new errors
Ege: we need to know which the subscription the error belonged
Cristiano: right, which is why prefer the first option
Daniel: a generic error listener also means the client has to
filter (also mentioned by Ege)
Zoltan: so we could revert to a kind of Observable
Jacob: I thought about adding an error listener to the
observe() and subscribe()
Daniel: I see benefit in managing it with a subscribe object
since we shift complexity
... the implementation tracks subscriptions automatically
Zoltan: Kaz, what was the deadline for publication in last WG
call? end of September?
Daniel: I thought it was beginning of September
Zoltan: we have a lot of changes, we could also make 2
publications
Daniel: we should make less publications since implementations
need to change
... node-wot would wait for the revised API
Kaz: publication time is based on the TF decision
... could be done quickly or we can wait for another update and
publish the document a bit later
Zoltan: we should go by DP's proposal and adjust the
publication date
Kaz: please note that Scripting API is a WG Note for the
current Charter
Zoltan: what about versioning the Scripting API itself
Daniel: not sure will it be a URL or a version string
Zoltan: do we have a need for an interface file def with a
given version as a package dependency?
Ege: for what use case, for telling old or new APIs apart?
<Ege>
[14]https://github.com/eclipse/thingweb.node-wot/tree/master/ex
amples/templates/exposed-thing#change-from-version-06x-to-07x-f
or-exposed-things
[14] https://github.com/eclipse/thingweb.node-wot/tree/master/examples/templates/exposed-thing#change-from-version-06x-to-07x-for-exposed-things
Zoltan: node-wot defines a version and also refers to the
Scripting API spec it implements
Daniel: it defines a version right now, it includes TS
definitions that are also published on npm
Zoltan: anyway it's doable to include the TR link for Scripting
from node-wot
... we need a label that we can easily connect the two
Cristiano: I agree, like node-wot is implementing the 0.8 API
spec.
... another issue is that in TS we can add links back to
definitions
Zoltan: makes sense
Daniel: the problem is that if you update the spec we need the
permalinks
issue #244
Zoltan: there is validation for consume() and not for the
construction
Cristiano: it should be the other way around
Zoltan: constructor is just a JS object constructor
... validation needs a factory method
Cristiano: validation could be done synchronously
Daniel: consume() and constructor should do the same
Zoltan: looks like that is possible
... ok, so let's change the issue name and track it there
Daniel: we have similar issue for produce()
Zoltan: let's continue the discussion next time
Ege: a quick question, for reviewing created a fork and empty
branch, should I make the PR in the Scripting?
Zoltan: AOB
adjourned
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [15]scribe.perl version ([16]CVS log)
$Date: 2020/08/26 10:50:07 $
[15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[16] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 7 September 2020 06:52:36 UTC