- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 07 Oct 2020 20:14:50 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/09/28-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
28 Sep 2020
Attendees
Present
Kaz_Ashimura, Daniel_Peintner, Tomoaki_Mizushima,
Zoltan_Kis, Cristiano_Aguzzi
Regrets
Chair
Zoltan
Scribe
zkis
Contents
* [2]Topics
1. [3]Past minutes
2. [4]PR 247
https://github.com/w3c/wot-scripting-api/pull/247
3. [5]Issue# 256
https://github.com/w3c/wot-scripting-api/issues/256
4. [6]Versioning
5. [7]Next call
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribe: zkis
Past minutes
<kaz> [10]Sep-21
[10] https://www.w3.org/2020/09/21-wot-minutes.html
Minutes approved.
PR 247 [11]https://github.com/w3c/wot-scripting-api/pull/247
[11] https://github.com/w3c/wot-scripting-api/pull/247
Daniel: we could point him to the latest spec to check again.
DP commented to ask re-review
Issue# 256 [12]https://github.com/w3c/wot-scripting-api/issues/256
[12] https://github.com/w3c/wot-scripting-api/issues/256
Daniel: similarly, we could ask Jakob if he's happy with the
changes.
Cristiano: looks like we didn't handle the problem.
Zoltan:
[13]https://w3c.github.io/wot-scripting-api/#the-emitevent-meth
od
... the problem is that specific error handling is specific to
the protocols
... the spec leaves it open to the implementations
[13] https://w3c.github.io/wot-scripting-api/#the-emitevent-method
Daniel: we could create one notification that opens up info
about error conditions
Kaz: I wonder if we defined enough set of possible errors
... if not, we might want to extend that set
Zoltan: I wonder about 3 solutions: handle it on TD level, or
as implementation detail, or can we define a generic enough
mechanism to include an algorithm in the spec.
Kaz: right, also thought about two possible directions, (1)
defining abstract level of errors within the Scripting API
and/or (2) deferring error handling to the Binding Template. I
don't think we can resolve this issue at the moment and would
suggest we work with the Binding Template TF collaboratively.
Daniel: inclining to leave it to the implementation
... it is up to the TD to define the errors
... might go beyond Scripting spec scope to define those errors
... we can ask Jakob if this is fine
Cristiano: that reasoning could apply to other interactions as
well.
Zoltan: we used to have this same problem when starting to
discuss error handling in general, and either we don't have a
good error mapping or it's problem because fingerprinting
Cristiano: we could handle it on the ExposedThing
implementation side
... only there
... we could add algorithmic steps for handling internal
errors, reported to the impl script, like with invokeAction()
Zoltan: yes, that would be a first step
... let's take a look on the emitEvent algorithm
Cristiano: emitEvent should throw, and we could also convey the
error through the protocols if supported
... but that is tricky
... kind of agree it's implementation detail
Zoltan: if we throw an error, it has to be in the spec
Cristiano: the split error handling is a bit of a mess
Kaz: this discussion reminds me of the relational database
engines. If we want to handle detailed errors, we could have 2
levels.
... one level handled by the Scripting API, the other by
protocols
Zoltan: we do it like that now, some errors are mapped and some
others left generic
Kaz: we could have a specific API for the details
Zoltan: not clear if supported by the TD, or the TD spec
Kaz: which is why I'd like to defer this discussion to a
broader group
Daniel: we could open an issue on the TD side
Zoltan: we already did file an issue
Cristiano: also for discovery
Kaz: and for security
... we need to provide capability of rolling back sessions on
fatal errors
Zoltan: then we need a transaction oriented API
Daniel: this puts a lot of pressure on the runtime impl
Kaz: we cannot get a nice and easy solution
Cristiano: I agree
Zoltan: anyway we could do a PR to make the algorithms more
exact and note about the open issues
Cristiano: we should also solve the promise vs error callback
Zoltan: we could follow the design of the discovery API:
constructor and start() method
Daniel: personally I would not touch that now
... first let's implement and experiment with it
Zoltan: Cristiano has a point and we should not leave it like
this.
... this needs to be fixed at the TD spec level
Daniel: we could keep the terms close to the TD spec, but if we
have a better solution in Scripting, I am open
Zoltan: what dependencies we have beyond node-wot?
Versioning
Zoltan: what about automatic ticking of the versions for PRs
Daniel: the only time we need a version is when we publish
Zoltan: then we can do it manually
Cristiano: I see the point to use the 3rd number to increase
every time, since we can reference the snapshot right away
Zoltan: we could automate the 3rd number and we could use only
the major and minor for releases
Daniel: we would also want to see the spec for each version
tick
Zoltan: we could include links too, to commit id and to
rendered version
Daniel: what about the TS definitions, they are done manually
Zoltan: IMHO we should mandate the TD definition update from
the PRs
Cristiano: I would do that automatically, too
Daniel: we need tooling for that
... node-wot doesn't fetch it, it's a manual process now
Next call
Daniel: F2F starts after the call
Zoltan: then let's have the call next week
... we will create a shared presentation and anyone could
contribute
adjourned
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [14]scribe.perl version
1.152 ([15]CVS log)
$Date: 2020/10/05 07:54:05 $
[14] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[15] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 7 October 2020 11:14:55 UTC