Re: [scripting] management interface

On Tue, Apr 11, 2017 at 11:24 AM, Hund, Johannes <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