Re: [scripting] management interface

On Tue, Apr 11, 2017 at 10:38 PM, Kovatsch, Matthias <
matthias.kovatsch@siemens.com> wrote:

> -        The management interface should be bound to a Thing managing a
> Servient. Its specification should come through standardized vocabulary
> describing the necessary Properties, Actions, and Events. It shall not be
> specified at the Scripting API level: this one is for the local API within
> a Thing and contracts with the Resource/Interaction Model from the top; you
> are talking about a remote API that involves protocols / messages going
> over the network, which is specified through the TD: Properties, Actions,
> Events. Furthermore, management features are not central for all types of
> Things. Thus, it should not be part of the common core. It fits much better
> to the application space, where features can be added etc. Interoperability
> is enabled through the standardized management vocabulary.
>
> At the Scripting API level we only have 2 methods: creating a Thing
> (described by a Thing Description) and modifying a Thing (Description). The
> Thing contract is described in the TD and in the registered request
> handlers, actions and event handlers, all of which is in the application
> space. So I don't see a conflict here. Actually I've been saying the same:
> instead of a dedicated management API we should use the Thing abstraction
> to solve the use cases.
>
> MK: But you are defining two functions that carry out network functions
> that are then outside the narrow waist of Properties, Actions, Events. You
> indirectly define a Thing through the function signatures.
>

That is incorrect, Things are created based on TDs, not based on function
signatures. This has been part of the Scripting API for long time. Also,
adding/removing properties, actions and events, and defining handlers. It's
there in the current practices and has been iterated over many plugfests.
https://w3c.github.io/wot/current-practices/wot-practices.html#createThing



> Even if the create() with a remote target and the “RemoteExposedThing”
> internally build on top Properties, Actions, Events, we blur our narrow
> waist.
>

"Narrow waist" is a term I keep hearing in different contexts, but don't
understand what do you mean in this context. Server API already has "narrow
waist".

In my understanding, the use case and purpose of WoT Scripting API is to be
able to use, define and manage Things with scripts.
Obviously, most methods in the Scripting API involve network functions that
are encapsulated by the WoT Runtime.
Obviously, scripts may affect local and remote WoT stacks - that's the
whole purpose of WoT scripting.
Obviously, server API implementations use local platform APIs that are
encapsulated by the server runtime (and interaction model), so they are
never exposed externally. There is nothing blurry there.

I do recognize that this proposal is a simplification of the existing model
and involves re-evaluating some of the pictures and statements in the
Architecture document. I think part of the problem is that there are
different assumptions at work now.
https://w3c.github.io/wot-architecture/
We need to do some alignment.
Johannes: I propose we discuss this on one of the next scripting calls.



> Why must this be part of the runtime standard? Where does it stop? We are
> creating a tight coupling between an orchestrating Thing and a managing
> Thing. The management interface exported over the network needs to be
> defined by a TD with a Thing management vocabulary identifying the
> Properties, Actions, and Events. Defining these function in the Scripting
> API basically says our model is bull and all we want well defined RPCs. It
> breaks the overall concept.
>

Again, scripts can discover, access, define and redefine/update Things.
This functionality is already there.
The scripts are run in a WoT Runtime, which is also a security enforcement
point.
There is no "RemoteExposedThing", just "ExposedThing".
We do not expose local platform APIs through the network.
The protocols underneath are encapsulated and owned by TDs and bindings.

In the client runtimes that don't have access rights to create things,
creation/deletion/update of TDs/Things will simply fail.
It is orders of magnitude simpler model than presenting a different
interface based on a combination of dynamically evaluated capabilities,
permissions and policies. Some WoT runtimes will be only able to
"orchestrate", some will be able to "manage" Things. These words reflect
capabilities. Capabilities should be provisioned and configured in an
orthogonal way from Scripting.

If we'd separate discovery + access in one API, and define+redefine in
another API, the API usage and implementation would not be simpler, just
different. I much prefer a flat API object where methods fail, rather than
presenting multiple interfaces. This has been the preference in Web
standards, as specs are much simpler, and algorithm definitions can
contain/handle the constraints.

I propose we discuss and clarify this in a call.

Also, I suggest reading and reviewing the proposed Scripting API and
rationale doc and discuss on the PR.
https://github.com/w3c/wot-scripting-api/pull/21
Rendered versions:
https://zolkis.github.io/wot-scripting-api/
https://github.com/zolkis/wot-scripting-api/blob/master/rationale.md#wot-runtime-applications-scripts-things


> The security, in particular access control, can be defined on the
> Interaction Model. This even allows more flexibility: more complex
> Servients can use more complex authorization mechanisms.
>

I agree on that, and it's been described in a compatible way in the
Scripting rationale doc.
BTW the interaction model is encapsulated by the WoT Runtime/Scripting API
and belongs to the bindings.
https://github.com/w3c/wot/tree/master/proposals/explicit-bindings
https://w3c.github.io/wot/proposals/explicit-bindings/abstract-transfer-layer.html


>
>
> You can use code modules to be imported if you are worried about writing
> the code that instantiates a Thing by using Properties, Actions, and Events
> of a remote Management Thing for every orchestrating application again and
> again.
>


Define code module, define import (what, to where, by whom).

In my understanding it is a developer choice whether to have a "management
thing" or a script that simply deploys a set of Things and updates another
set of Things for implementing a given use case.

The code written using the Scripting API will instantiate Things by using
Properties, Actions and Events on a local or a remote WoT Runtime.
What do you mean by the need to be done again and again, I don't get the
point there. It's either point to point, or point to multipoint
distribution and happens through the interaction model based on the
underlying protocols.

Also, I mentioned in the scripting rationale that deployment model (direct,
or repository) and its provisioning/configuration is orthogonal to the
Scripting API.

We should clarify the assumptions on architecture and provisioning vs
scripting.

Best regards,
Zoltan