WoT Scripting API

<scribe> scribe: zkis

Daniel: presents the agenda

Previous minutes

<kaz> Nov-9

Daniel: any objections?
... minutes approved

node-wot issue 333

https://github.com/eclipse/thingweb.node-wot/issues/333

Daniel: summarizes the issue and past discussion
... ZK provided a PR to fix

PR 283 https://github.com/w3c/wot-scripting-api/pull/283

DP presents the PR

Ege: I am fine with removing the inheritance

Zoltan: everything must be done manually now from ExposedThing
... in order to gain experience on what is worth standardizing later

Ege: wondering how does this affect the example code
... should emitPropertyChange also contain the value

Zoltan: no

Cristiano: if the read handler is instantiated, then the impl can figure out the value

Daniel: is this actually needed?

Cristiano: yes
... this pattern is used on every single Observer use case out there

Zoltan: let's keep it manual and simple and see what to automate later

Daniel: but you need to set the value before emitting property change

Zoltan: now the impl only abstracts the underlying protocols

Ege: emitPropertyChange() triggers the read property handle, gets the value, and compares?

Zoltan: no, it doesn't compare

Cristiano: right, the runtime will emit the change notifications

Daniel: asking about providing the value

Cristiano: that would create another confusion

Zoltan: yes, it's only a notification about value change, not all protocols will actually send the value

Daniel: I like that the script writer is in charge of everything
... but this will break all existing scripts

Ege: before there were some hidden things, do this is fine

Daniel: so the PR can be merged

Zoltan: I will squash some commits and will merge

Ege's presentation

<Ege> https://github.com/ajs124/wotest

Ege: this is a student project for comparing Scripting API implementations
... node-wot, wot-py, sane.city wot-servient
... TypeScript, Python and Java implementations
... he wrote a testing implementation in Golang
... also used docker containers
... client and server impl with a test runner
... starts different servers and runs the tests, checking the requests/responses
... compares implementation metrics
... also performance testing
... node-wot is about 10x faster than the Python impl
... wot-py uses the Tornado framework that is supposed to be fast
... CoAP is about 2x faster
... than HTTP
... other implementations can also be tested against the existing ones

Zoltan: what is the license and can we use it in W3C WG as testing FW

<dape> https://github.com/w3c/wot-scripting-api/issues?q=is%3Aissue+is%3Aopen+testing

Daniel: does it test completeness?

Ege: right, it is not a functional and coverage test

Kaz: we have testing FW for the browser and other implementations
... could we use these in the W3C testing FW?
... we should discuss the details in the plugfest call but we should improve the testing environment

Cristiano: this performance comparison was interesting and useful
... would it be possible in the future to test the compliance level, too?

Ege: that is quite complicated since we have to wrap scripts and deploy them and also instrument them
... ATM there is no established way how to do this

Cristiano: there is the testing FW for browser API

Zoltan: WPT is browser specific and we should have similar ones in the Node.js world as well
... anyway it's good we have this performance testing framework

Daniel: right, and we could include the link in the tools
... a third impl was mentioned, what was that?

Ege: the github source is not actively maintained

<Ege> https://github.com/sane-city/wot-servient

Cristiano: they implemented discovery, even though it's still discussed actively

Publication

Kaz: working on the document check for the FPWDs
... maybe on Thursday we could make it

Zoltan: next meeting agenda will be shared, and we can discuss next steps

[adjourned]