AW: [scripting] management interface

Hi all,

> What is important here IMHO is to identify the _minimal_ set of mechanisms that
> need to be explicitly exposed via the Scripting API in order to be able to implement
> these use cases.  

I absolutely agree. The most elegant solutions are the simplest that scale also large without introducing overhead at the small starts.

> 1) One question is the definition of an Application, in relation to the Application
> Contract (Scripting API) and WoT Runtime.
> How an Application is defined, identified, certified, stored, deployed, started,
> stopped, uninstalled etc.
> Is it a script, or a set of scripts, plus configuration data and eventually the
> equivalent of a manifest?
> Or could it be represented as a Thing with a TD?

We have been discussing this also, as there might be cases where you need a manifest as to what an application does, which rights it needs to that, or if it has dependencies (other things need to be there).
You could take it as far as having configurations and parameters (e.g. for the canonical heating controller - the URIs of the temperature sensor and the valve) that are "bound" at runtime.
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.

> 2) This means the management interface, eventual sandboxing  and security
> enforcement point can be provided by the WoT Runtime that contains the Things
> without further abstraction levels needed. The management interface is reduced to
> 2 functions: (see https://zolkis.github.io/wot-scripting-api/#the-wot-api):

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

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

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

Best regards,
Johannes

Received on Tuesday, 11 April 2017 08:25:12 UTC