Re: [scripting] management interface

Thank you Dave for bringing up this topic, we definitely need input from
the larger group on this one. It involves multiple levels across the stack.

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?

To summarize the existing input we have, people tend to view an Application
as a (set of) script(s) + data represented in serialized form as files in a
directory, or a single serialized file that can be deployed across WoT
Runtimes. That begs the question what a WoT Runtime is and how does it run
(multiple) scripts. However, the main use case for scripts seems to be to
define Things that will interact with each other in the same or in
different WoT Runtimes.

Therefore, in the scripting call today we analyzed the possibility of
representing an app as a Thing, because:
- it has a TD that can be shared using existing mechanism, and can define
the metadata needed for manifest and configuration data
- it has a well defined abstraction level
- it simplifies deployment and management
- it simplifies the implementation of a WoT Runtime
- it seems to be more secure since some validation is possible through the
TD.
Note that Thing actions can be specified as scripts (serializable
functions).

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

- and the following method on `ConsumedThing`:
`Promise<ExposedThing> acquire();`
that based on an existing (discovered, or retrieved Thing) provides an
interface in a new ExposedThing object that permits changing the TD of an
existing Thing. This method provides full access of the Thing to the client
WoT Runtime, in order to control its full definition. Depending on security
policy on the source WoT Runtime, this access may be exclusive or shared,
and may or may not imply transfer of ownership (pending on security
recommendations).

3). The implementation of the two methods above will encapsulate the
necessary bindings and underlying protocol(s) used for implementing the
Thing/script management interface, including the security related
identification and access management functionality. Here come all the
specific protocols mentioned in Dave's email.

4) The provisioning level is out of scope for Scripting, and depends on the
underlying platform, such as OCF or OneM2M etc. However, the WoT WG can
make recommendation on what issues should be solved, with examples that may
include actual protocols.

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. IMHO this minimal set should not include
an explicit management interface such as the ones needed for OCF
provisioning and ownership transfer procedures.

This minimization can be rather complex, depending how do we define 1).
Therefore let's start at defining what an Application is. It would be
really nice to get input from the group.

Best regards,
Zoltan