Past minutes: https://www.w3.org/2020/01/27-wot-minutes.html
<scribe> scribenick: zkis
Discussing past minutes, about the order of priority if multiple Forms are present
Daniel: we should raise awareness of
the TD TF about this
... the issue is broader than just Scripting
... it's not related to the past minutes themselves, though
<scribe> ACTION: DP create an issue for Forms priority discussion in TD
Zoltan: can we approve the past minutes? Yes.
Past minutes approved.
Discussing error reporting mechanisms.
Zoltan: is it possible to map protocol errors to ECMAScript errors, or should we have separate mechanism for reporting
Daniel: we should be careful not creating too many error types
Zoltan: do we have mainly CoAP and HTTP bindings?
Daniel: in node-wot we have more
Zoltan: the TD doesn't really describe errors
Daniel: right
... the reason Ege raised this was because node-wot returned
generic errors too often and it was hard figuring out the
underlying error conditions
... without looking at the actual error message
... Ege is working on the testing tool
... we need to look at each method in the Scripting API and
figure more meaningful error reporting
Zoltan: we cannot expose all error information in Scripting because of fingerprinting
Daniel: at least with HTTP errors it
would be nice to share detailed error information
... at least the error codes
Zoltan: could apps tell which bindings (Forms) are being used by implementations?
Daniel: right, they cannot tell and
cannot affect currently
... other than we currently pick the first available
... (in node-wot)
... so yes, if we get a failure, we don't know which bindings
were used
... to start with, we can use better errors, and then we could
expose which bindings were used
Zoltan: since we don't have too many
protocols, we could include an informative table on how we use
errors
... this concludes the list of issues that needed discussion
before we update the spec
Daniel: there should be an error if a write handler is registered for non-writeable property
Zoltan: but this is a way the app can
implement the enforcement policy
... or do we want to deprive apps from specifying that and
should the runtime enforce the TD policies?
Daniel: so it would be just a Note that implementations (of ExposedThing) are actually the ones that implement the policy
Zoltan: when we create ExposedThing, do implementations generate a TD?
Daniel: apps should provide the TD
strings themselves
... using the produce() method
Zoltan: but then the "annotations" should be part of the TD (and standardized with the TD)
Daniel: right
Zoltan: do we need a generic FW like https://github.com/web-platform-tests/wpt/ ?
<dape> TUM has https://github.com/tum-esi/testbench
Zoltan: so it's under work now
Daniel: we could use Websockets for very high frequency updates
<McCool> mccool: I will have to drop soon to prep for security call
McCool: I hope we could leverage we
already have
... we need to gather more exact requirements
Zoltan: also client-side policies,
e.g. how much data can it consume how often
... are restrictions imposed by JavaScript etc
McCool: depending on abstraction
level, we could get JavaScript away
... just used for setting up
... we should check similar problems on other places.
Adjourned.