AW: [scripting] management interface

MK: But you are defining two functions that carry out network functions that are then outside the narrow waist of Properties, Actions, Events. You indirectly define a Thing through the function signatures.

That is incorrect, Things are created based on TDs, not based on function signatures. This has been part of the Scripting API for long time. Also, adding/removing properties, actions and events, and defining handlers. It's there in the current practices and has been iterated over many plugfests.
https://w3c.github.io/wot/current-practices/wot-practices.html#createThing


You proposed:
` Promise<ExposedThing>     create(ThingInit init, optional USVString target);`

Whenever target is not local, you implicitly assume that there is a channel to the remote runtime with local and remote stubs, network interfaces, and a protocol between them. You are making assumptions about concrete network interface from the Scripting API. This is wrong.

`Promise<ExposedThing> acquire();`

With this you transparently instantiate a local proxy that again is connected to a remote runtime using local and remote stubs, network interfaces, and a protocol between them to forward and realize the changes that your script does locally on the proxy.


"Narrow waist" is a term I keep hearing in different contexts, but don't understand what do you mean in this context. Server API already has "narrow waist".

„Narrow waist“ is used in two ways:

a)      to promote the idea of WoT by comparing it to what IP did as narrow waist for the Internet.

b)      to promote the benefits of the Uniform Interface constraint of REST.

In my understanding, the use case and purpose of WoT Scripting API is to be able to use, define and manage Things with scripts.
Obviously, most methods in the Scripting API involve network functions that are encapsulated by the WoT Runtime.

The use case and purpose of the WoT Scripting API is to implement application logic WITHIN a Thing. This encompasses exposing interactions/resources as server and consuming resources of other Things as client. These interactions have to go through the narrow waist, a uniform interface with a limited set of methods: getProperty, setProperty, invokeAction, <something>Event.

Obviously, scripts may affect local and remote WoT stacks - that's the whole purpose of WoT scripting.

Things cannot affect remote stacks. To be the glue between existing platforms, we must not make assumptions about their implementation. We only have the contract of the Thing Description. We can only offer nice building blocks such as a standardized runtime for application logic; but only a subset of devices will actually implement this, as it also depends on available resources.

Obviously, server API implementations use local platform APIs that are encapsulated by the server runtime (and interaction model), so they are never exposed externally. There is nothing blurry there.

Yes, they are exposed to the local logic through the Scripting API and to remote (networked) Things through the TD contract.