Define UA/runtime for WoT

[zolkis]

A User Agent in a browser is a runtime that acts on behalf the user and is part of the security model that is based on user approval.

It is difficult to define a user for WoT.

Should we use a specific term for WoT Runtime, or WoT UA or something else?

Temporary formulation:

A WoT runtime or simply Runtime is defined as a software stack that manages the lifecycle of WoT application scripts. In the case of ECMAScript and TypeScript scripts, it consists of an ECMAScript interpreter, script lifecycle management, and an operating system API that provides access to local and remote resources. A WoT Runtime can be modeled as a virtual machine in the sense that it should be completely isolated from other execution environments on memory address space, storage address space (file system), network namespace, etc. A runtime may be for instance a Node.js environment, an embedded runtime based on a small JavaScript engine, or provided by a browser.

[knimura]

As you described, assuming a WoT Runtime is modeled as a VM.
It can say that WoT Runtime has three types: WoT Client / WoT Server or WoT Servient on VM. Then each of WoT Runtime can be realized by Node.js.
Especially regarding WoT Client, it can be realized by a browser (UA) extension as well.
Since it just a choice of the mean of WoT Runtime, I think the term of “WoT UA” does not need to define.

[zolkis]

I agree. Let's use the full term WoT Runtime in the spec until a better term is advised.

[h0ru5]

As mentioned in the call on 06-03-2017 we should clarify also the relation of scripts, runtimes and things

[zolkis]

IMHO we have 2 options for Runtime vs Thing vs Scripts modeling.

1. A Thing is associated with its own runtime and interacts with other Things only via the WoT interfaces. Local physical interfaces are encapsulated by bindings. Bindings/implementations may take advantage of local optimizations, but Thing addressing and interfaces don't change based on locality. A script run on a Thing can access other Things based on this standard interface. Script collation/combination is possible following distributed programming paradigms.

2. More similar model to OCF. We introduce the notion of a WoT Runtime (equivalent to OCF Device) that run scripts that expose/have access to all local Things using a "local" interface that is different from the "generic" one used for accessing remote Things in general. In OCF, a resource has a single URL for addressing, which is composed of a scheme, a device ID (or IP address) and a resource path. So Thing identification would not be opaque string, but a structure that can be serialized to a URL and vice versa, can be obtained from a URL. In the runtime, the resource path is enough to identify the Thing, outside the device id is also needed. Scripts can operate with values independent of network address space, that is, device id + resource path that are mapped e.g. to IP address and port. URL scheme selects the protocol. A script can operate with multiple local Things using a simpler interface and would use remote scripts the same way as 1.

Both models would be capable of serving Thing and script aggregation/combination use cases, but IMHO 1. is more adherent to the mission of WoT, i.e. to be an abstraction layer above IoT that connects Things not only via protocols, but to the Web. So rather than replicating or redefining the existing complex IoT models, we'd need a simple and nevertheless powerful concept.

IMHO we should strive to a representation that makes runtime configurations irrelevant for or orthogonal to Thing interactions. Moreover, we should be able to move/migrate Things around runtimes without strong ties. Therefore IMHO we should try using 1. with opaque URL addressing.

[zolkis]

We also need to figure out how do we plan to manage scripts: provisioning, configuration, running, etc. This should be a separate deliverable than the Scripting API, but they are connected.

I imagine the primary role of a script is to define, expose, represent and encapsulate a Thing with all related HW and SW (that can also contain other scripts).

The Script Management Interface (SMI here) allows updating a Thing defined on a HW platform without re-flashing the device - so it's a kind of package manager, possibly connected to TD repository or even a Things Store.

HW platforms can define Things without SMI support if they want to control the exposed Things' lifecycle. Most small embedded devices will fall here and we hope WoT can be fit to be supported there by manufacturers.

HW platforms that expose a package manager interface, can be updated to support either Wot SMI or "Things as native packages".

These are just preliminary thoughts. Please share your views.
@knimura @draggett @h0ru5 @mkovatsc @mmccool @mjkoster

[knimura]

Scripting API deals thing lifecycle as defined in the WG charter. So SMI should be part of it.

[zolkis]

Scripting API deals thing lifecycle as defined in the WG charter. So SMI should be part of it.

Based on the Current Practices, a Thing has WoT interfaces facing the external world, and the Scripting API is an internal API between a script and the model/bindings.

The SMI would be an external facing API for managing scripts, so IMHO clearly different from the Scripting API. I don't know if it's good to include it into the WoT interface, or it'd better be a separate interface at similar level as the WoT interface, but either way it's not there now and we need to add it - if we need it.

[draggett]

Provisioning in the broader sense is a key requirement, and for me includes the ability to update apps running on a Web of things application platform. This is broader than just script files and extends to all of the resources needed by an app.

We also need to consider the resources that make up the application platform itself. These include the drivers for the supported IoT technologies as well as security related resources.

Secondary storage will in many cases be on Flash memory, so I would expect this to involve updating Flash memory.

[zolkis]

Yes, there is provisioning that is connected to the underlying platform, for instance OCF provisioning with the resources needed (security keys, certificates, doxm resources etc). AFAIK OCF allows application specific provisioning data as well (from their point of view WoT is an application), but this might change. This part belongs to the WoT bindings since it's platform dependent. This kind of provisioning is out of scope for scripting.

What I am asking is that do we need or want a mechanism to deploy WoT scripts to WoT runtimes without re-flashing (where the underlying platform supports that). This would be similar to how web pages can fetch scripts. That interface is what I referred to as SMI (script management interface).

Since the main thing SMI would do is to allow fetching remote Things, @knimura is right that we might say we solve this using the Scripting API, but I would add only if the TD can contain scripts as well and we allow execution of those scripts -- to which security people would likely say no-no. So
on a second thought, SMI may not be a good idea, it's too generic, therefore potentially dangerous.

One way out would be to allow TD's to contain recipe/rule/scene/scenario definitions that are composed of operations predefined and standardized in the WG and can be security-hardened. This way when we retrieve a remote Thing (as ConsumeThing), its TD would contain these scenario definitions that the importing script could use in order to combine Things functionality. Now for that we could have support in the Scripting API - if we vote for this model.

[knimura]

I'd like to clarify what kind of script would be dealed in the SMI and what the recipe/rule/scene/scenario definitions look like .
Could you explain based on the voting scenario in the rationale.md (1-3-2. Example: Voting) if possible?

[zolkis]

In rationale.md you mention that a script has to get to the application layer of a Thing. I am talking about all these scripts and how exactly do they get to the Thing.

If the answer is by flashing only, then IMHO WoT is just like one of the IoT islands it tries to abstract (which also try to abstract other islands).

What I'd like to get is WoT provisioning based on native application concept, and then WoT applications deployed and run through a WoT interface.

TD is one step towards that direction but IMHO not enough. Currently with OCF you can develop a script by reading documentation/RAML then deploy it. This can happen even via a browser, even to microcontrollers. Even though the data model is static, the scripts can be upgraded easily without re-flashing, which is IMHO more generic than just adapting to data model changes with static scripts.
(Discoverable and downloadable TD are more generic then these doc/RAML and allow more generic code that makes data model updates transparent. However, scripts would be still static wrt business logic.)

We could also say there are different levels of WoT configurability, on some devices WoT support will be flashed, on other you could create dynamic Things based on other Things. This could be dictated by the support level of the native platform.

In any case, if we support dynamic WoT at all, we will need to define the script (or recipe) management/lifecycle - which we currently lack.

[knimura]

It would be part of Scripting API if the script is related to an API and the hook. I agree this is not there yet but it would be optional function since flashing also can be the solution.
In the voting example, three scripts in WoT Servient would be part of the new life cycle because the scripts deal hooks. However voting script for WoT Client would be out of scope because it just tries to use the API.

[h0ru5]

there are much topics in a single issue, but I'll try to comment:

• SMI: i like the idea to have a standardized interface to deploy/start/stop/restart/delete a script - so far we have modeled that as a "thing"-interface itself (i.e. actions and properties) in our implementations - a thing representing the runtime.
• runtime / thing / script:
  in my current thoughts, the runtime hosts one ore several things and runs scripts. these scripts interact with the runtime and can expose things, modify local and remote things and react on events in local things.

[h0ru5]

maybe to add: the SMI would indeed need two interfaces, one which is the interface I use in my script to react to lifecycle events ("you are being stopped") and one which is exposed so that others can interact with it.
I'd opt to name it "WoT Runtime Interface"