Re: [scripting] management interface

Hello all,

 It was impossible for me to assist today's meeting and it seems to be very
very interesting. I think that scripts are scripts and things are
things...and should not be room for many more concepts. Only things (which
are abstractions like traditional objects in OOP world). In my opinion
there are no room for apps. Programmers do not create apps, they create new
things (usually abstract things). As in traditional webs there are only
pages...and everything are webpages. Even, thing description could be
mutable, so programmers can add new behaviour by "installing" new
operations provided with scripts. To do so, maybe they should  expose any
kind of meta-description (perhaps using a predefined semantic context).

Regards,
Ángel Retamar

El El lun, 10 abr 2017 a las 20:28, Kis, Zoltan <zoltan.kis@intel.com>
escribió:

> 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
>
> --
*Angel Retamar Arias*  |   *Unit Manager | Web of Things*
@: angel.retamar@fundacionctic.org | Skype: angel.retamar.fundacion.ctic

[image: CTIC]

*CTIC Centro Tecnológico / W3C España*
Parque Científico y Tecnológico de Gijón
C/ Ada Byron, 39  | 33203 Gijón  |  Asturias  |  España (Spain)
Tel: (+34) 984 291 212 <javascript:void(0);>

Movil: (+34) 6558832239

Web <http://www.fundacionctic.org/>  |  Twitter
<https://twitter.com/fundacionctic>  |  LinkedIn
<https://www.linkedin.com/company/fundacion-ctic>  | Privacidad
<http://www.fundacionctic.org/privacidad>

[image: European Innovation Partnership on Active and Healthy Ageing.
Partner plus]
<http://www.fundacionctic.org/lineas-de-especializacion/bienestar-y-envejecimiento-activo>