03 Feb 2020


Kaz_Ashimura, Daniel_Peintner, Michael_McCool, Tomoaki_Mizushima, Zoltan_kis


Past minutes: https://www.w3.org/2020/01/27-wot-minutes.html

<scribe> scribenick: zkis

Minutes from the previous call

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.


Summary of Action Items

[NEW] ACTION: DP create an issue for Forms priority discussion in TD

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/02/11 08:13:17 $