WoT Scripting API

20 September 2021


Cristiano_Aguzzi, Daniel_Peintner, Jan_Romann, Kaz_Ashimura, Tomoaki_Mizushima, Zoltan_Kis

Meeting minutes


Daniel: last week was canceled

approving previous minutes

<dape> Sep-6

Daniel: Jan Romann joined the call

DP presents the summary of last meeting

no comments, minutes approved

test fest

Daniel: by the end of September
… we need to prepare the topics
… we can play with the "new" API _and_ implementation

Zoltan: has discovery been used?

Daniel: not implemented yet
… still under discussion

Daniel: there are 2 proposals, from Ben and Cristiano
… about canceling actions
… one proposal provides a handle with which the action can be referred to later (e.g. canceled) based on a TD
… that was Cristiano's
… Ben's proposal is more static, described in the original TD

Daniel: does anyone plan to explore these aspects during the testfest?

Cristiano: will work on his proposal to test it
… also will try to test discovery

Jan: experimented with multicast discovery and CoAP - this has been removed from the spec
… we can experiment with these

Daniel: we have stripped down discovery a lot and will wait until it stabilizes

Daniel: the implementation is using a multicast group address (CoAP, IPv4, IPv6)
… send request to well known URI
… go through the list of links obtained and send GET requests to get further data, e.g. resource type
… there have been concerns about multicast in general

Kaz: during the architecture call on the 16th Sept there was discussion about canceling actions
… if someone from Scripting can provide a device for that discussion, would be nice
… can we do that at all?

Daniel: we try to implement a server that respects the WoT Profile (i.e. Ben's proposal)
… we can launch a dummy action and then try to cancel it

Kaz: we should list the proposals to be handled this time, the experiments and record the results on the TPAC Plugfest page

<kaz> TPAC Plugfest/Testfest page

Zoltan: was it considered to provide explicit canceling actions for certain actions, instead of generic cancelable interactions (and only for Action interaction)?

Daniel: yes, that should be considered

Daniel: the use cases are important, we should test both use cases and proposals

Cristiano: in Ben's proposals everything is written in place, using different op types in the Form
… in my proposal, an action carries a TD where you find the operations relevant to that action

Zoltan: this has been discussed few times (to return a Thing from an interaction), but could we flatten that recursive definition?

Cristiano: this proposal is new in the sense that now we have Thing Models
… so we can say how Actions will look like, so we have both static and dynamic descriptions of interactions

<dape> https://github.com/w3c/wot-thing-description/tree/main/proposals/hypermerdia-control-3

Cristiano: we have Action queues, some protocols allow these - Ben is solving this by another op type
… we can have a mixed solution

<kaz> Ben's proposal on actions

<kaz> Cristiano's proposal on actions

Zoltan: I am not opposing dynamic interactions, we should experiment with them

Cristiano: Ben's proposal is less interoperable since needs rules on how to use them
… in Core Profile all actions should be cancelable and queryable

Daniel: Ben's proposal gives you a href which can be used for controlling
… e.g. with the queryaction op

Daniel: with Cristiano's proposal only a subset of a TD is returned with an Action

Zoltan: can we generalize to all Interactions return a TD? Does that make sense, or do we keep Actions special?

Cristiano: we could do that, e.g. for collection, but needs more thought

Zoltan: so we need to test how much effort it takes with each proposal, both for developers and spec implementers

Kaz: I believe concrete use case scenarios including app setting should be considered (i.e. a specific discussion)
… e.g. Oracle products, Siemens products etc to be handled by node-wot
… which part is implemented by node-wot and how other implementations work
… this should be clarified
… given that, we can understand what kind of interactions we need to support
… for instance, if Scripting TF goes for CA's proposal implementation, which systems will use that and which ones Ben's proposal?

Daniel: the PR from Ben was merged for people can try it
… so we should be able to explore also CA's proposal

Kaz: we should clarify the node-wot use cases for the plugfest
… latest by the plugfest call on Wednesday

Cristiano: on the plugfest I would practically want to experiment interacting with Web Things gateway with node-wot + app

<dape> https://github.com/WebThingsIO/gateway

Kaz: who will provide that gateway?

Cristiano: I can play with that locally

Zoltan: I think that is possible and valid, no remote gateway needs provisioning

<kaz> network configuration for 2020

Kaz: the bigger problem is that plugfest preparation is delayed, and would be good to have network config diagram for this plugfest
… that should include the proposed tests
… and how to get connected to them

F2F topics

Daniel: we should also gather topics for the F2F

Zoltan: we should discuss how to expose bindings to apps, especially when WebThings encapsulates all but web protocols

Daniel: we can create a dedicated issue and start listing the topic

PR 339


Zoltan: looks good so far

Cristiano: some errors because ReSpec

Zoltan: we need to check recent ReSpec syntax

Daniel: time is up, continue on github


Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).