Re: [scripting] management interface

On Wed, Apr 12, 2017 at 4:22 PM, Kovatsch, Matthias <
matthias.kovatsch@siemens.com> wrote:

>
> 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.
>
>
>

We also implicitly assume there is a channel between two Things, including
network interfaces and a protocol between them. We are making assumptions
about concrete network interface from the Thing. Yet we are able to manage
this abstraction...

I proposed using the same abstraction for the use cases traditionally
solved by scripting. The reason for this was the problems we encountered
while trying to define a script management interface, which quickly
escalated into security and in-charter-scope type of issues. You are
welcome to propose solutions to these.

Between the two, IMHO managing remote Things is the easier and simpler.


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.
>
>
>
You have a clear preference in this regard. Noted.
Then you must also have a clear preference on script management. Waiting
for the proposal :).


> 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.
>
>

That would really break things. I'd like to see implementations of a
universal HAL and PAL in a WoT Runtime...