AW: [scripting] management interface

Hi all

I few short comments on this, as I am unfortunately quite under water at the moment:


-        Using TDs as manifests sounds reasonable. At the T2TRG meeting we discussed with security experts about the TD having a similar (or more powerful) functionality as MUD (https://tools.ietf.org/html/draft-lear-mud-framework-00): The starting point is that Manufacturer Usage Descriptions describe the intended network activity, so that network operators can now how a device should behave (how to intervene when not is out of scope). This could be added as security metadata to the TD and would nicely describe physical Things, i.e., devices. Same should be possible for virtual Things, i.e., scripts. One issue is that a script can potentially instantiate multiple Things…

-        The management interface should be bound to a Thing managing a Servient. Its specification should come through standardized vocabulary describing the necessary Properties, Actions, and Events. It shall not be specified at the Scripting API level: this one is for the local API within a Thing and contracts with the Resource/Interaction Model from the top; you are talking about a remote API that involves protocols / messages going over the network, which is specified through the TD: Properties, Actions, Events. Furthermore, management features are not central for all types of Things. Thus, it should not be part of the common core. It fits much better to the application space, where features can be added etc. Interoperability is enabled through the standardized management vocabulary.

Ciao
Matthias


Von: Kis, Zoltan [mailto:zoltan.kis@intel.com]
Gesendet: Dienstag, 11. April 2017 13:03
An: Hund, Johannes (CT RDA NEC EMB-DE)
Cc: Dave Raggett; Public Web of Things WG
Betreff: Re: [scripting] management interface


On Tue, Apr 11, 2017 at 11:24 AM, Hund, Johannes <johannes.hund@siemens.com<mailto:johannes.hund@siemens.com>> wrote:

However, I agree that it would be the finest way that this manifest is a TD and the application is just another Thing.
We as Scripting API TF should take care of how to write code / logic for the application - keeping in mind that there could be a plethora of deployment possibilities later - and overall as a WoT group only introduce new concepts if there is no way to express it in the existing ones. As I do not see that this is given, I also opt for expressing Applications/Scripts as Things rather than introducing a new concept.

Thank you Johannes. We should explore this path, and if solves our use cases, fine; otherwise we can introduce new concepts if needed.

> -  one at the global WoT Object:
> ` Promise<ExposedThing>     create(ThingInit init, optional USVString target);`
> that creates a new ExposedThing on a given target WoT Runtime (by default on
> the local one),

agreed. As discussed. Target is an URI that points to a Thing that is a servient resp. a WoT runtime The thing management interface (TMI maybe?) is there, it's just abstracted away from the application programmer (which is a very good thing IMHO. - a task for the plenum would be to define the vocabulary (@types of actions and properties) for this thing interface based on the use cases we see for such a management interface, which I would state for now as the methods of ExposedThing.

Input from the TD TF would be very much welcome. I propose we discuss this on the IG/WG call tomorrow.


> - and the following method on `ConsumedThing`:
> `Promise<ExposedThing> acquire();`

To confirm: This acquisition gives me an ExposedThing interface to a remote thing - it's a "privilege escalation". Under the covers, the runtime will check if this script is allowed to modify the interface of the (remote) thing. It does not guarantee exclusive access (the name could be interpreted like this) - if it would, we would need some kind of management to release it, with a fallback to a timeout etc...

The name may be changed, if a better one is found. This just suggests there is some kind of acquisition: it may or may not be exclusive, depending on the security policy of the underlying platform that is enforced at the far end.


This design makes sense to me, although I think we need to clarify points like:

- when I write a script that does something on a remote runtime (creating a thing wit so e actions etc.), I am in the situation that I write code that is partially running on my local runtime and partially on the remote runtime.

Basically the code the developer writes is a deployment script that runs locally or in an app store. What I imagine as a use case is something like this:
- As a developer of a functionality/app I have a certain HW board provided with a stack that has a WoT implementation
- I have a browser that supports the WoT Scripting API
- I develop code locally in the browser IDE (e.g. see https://01org.github.io/zephyrjs-ide/) using the WoT Scripting API
- I can test the code on a board that is locally connected through BLE or WebUSB or USB/UART etc.
- I write a WoT script for "deploying" my app for similar target boards, doing either of the following:
    - execute the deployment script in the local browser that accesses the target devices and creates/starts the Things the app consists of.
    - push the deployment script to a server that has deployment rights to the target devices (provisioning and configuration happens e.g. through a web portal such as store front or similar).

In either case, the script runs in one WoT Runtime and affects other WoT Runtimes.
It may also be possible to run the script in the local WoT Runtime, but due to limited resources of many target devices, I think the former case will be more common.

- when dealing with remote things, it needs to be easy to understand  for the script writer whether a function (e.g. an event-handler) is executed on the local runtime or on the remote one. Especially when dealing with javascript and its closures this can be a bit head-twisting (remember dealing with  "this" in JS )

Yes, the API should be intuitive enough to help that understanding and avoid confusions.

- some interactions like requiring modules (on the remote)  would move into the handler functions and those could be executed at a very different point in time, where it could still fail because of the module not being present. We could circumvent this by having a script running at "install time" (a thing initializer), or we restrict the remotely created things to use only the WoT API.

That is why I'd like to have a WoT Application defined. I also think that a given "app" (set of Things) may have dependency on other "apps" (other Things), but at this point I would resolve these at the deployment script level. IOW, for the moment a WoT app needs to be self contained before deployment, i.e. the developer makes sure all resources are available after deployment. It should be part of application testing.

At this point I would like to avoid standardizing mechanisms for managing "packages" and resolving dependencies. It could be done within the frame of the store-type deployment model, as such pushing it out of relevance/scope for the Scripting API.
Best regards,
Zoltan