Define WoT Runtime and Application

[zolkis]

This is a meta-issue to track multiple issues related to WoT runtime.

The WG should define the notions of an Application, Application Store, and Runtime in the architecture document. It is needed for instance by the WoT Scripting API. Also, need to define terms for isolating a WoT Runtime.

See also: w3c/wot-scripting-api#2

Based on my current understanding, a WoT Application consists of one or more Things defined with events and actions (scripts) that are executed in a WoT Runtime (WR).

The manifest of an Application would define whether the app should be isolated from other apps. --> The WG needs to define security mechanisms for this.

Also, recommendation(s) on Application Store entities should be made.

A given hardware may be able to run one or more WoT Runtimes, isolated from each other. One WR has a single event loop, but can run multiple Things, as parts of one or more Applications.

When Applications need isolation, should they be run in separate WRs? interactions with other Things happens via the WoT interfaces anyway.

[draggett]

Here is the architecture diagram as shown in the 2017-04-03 telecon. Note that it is neutral in respect to being in the cloud, network edge, fog or peer to peer. Apps are executed in a sandbox with access determined by the security policies as part of the application contract. Each app can interact with zero or more exposed or consumed things as needed.

[zolkis]

This popped up again in a Scripting issue discussion. Quoting from there the part that clarifies terms:

1. The WoT Runtime (a.k.a. servient) is the SW stack that implements the WoT [network] interfaces.

2. An optional part of the WoT Runtime is the WoT Scripting Runtime, for instance a JavaScript or Python or Lua runtime.

3. A (major) part of the Scripting Runtime (together with platform-specific code, security policies enforcement etc) is the implementation of the WoT Scripting API. The Scripting API spec targets only that implementation part. Inside the Scripting spec all the other parts of the system are referred to as "underlying platform" (following Web spec parlance) in generic sense, or named explicitly according to this (Architecture) document when going into details.