<scribe> scribe: zkis
<kaz> Sep-21
Minutes approved.
Daniel: we could point him to the latest spec to check again.
DP commented to ask re-review
Daniel: similarly, we could ask Jakob if he's happy with the changes.
Cristiano: looks like we didn't handle the problem.
Zoltan: https://w3c.github.io/wot-scripting-api/#the-emitevent-method
... the problem is that specific error handling is specific to the
protocols
... the spec leaves it open to the implementations
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?
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
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