[question] Is the servient a hypervisor or single application vm?

[relu91]

Hello, I have some doubts about the application scripts described in section 8.1 of the latest draft. In particular, is not clear to me if the servient is meant to run one application at a time or if it more like a hypervisor where multiple applications can be run and stopped at will.

I'm not sure if this is more an implementation detail but I'd like to have a more deep understanding of this topic because we are working on this is issue and knowing this detail will make a difference.

[zolkis]

IMHO (and according to the WoT security doc) a script should be run isolated.
ConsumedThing and ExposedThing objects should only use the WoT interactions for communicating.
I would put start() and stop() at the API object level, not to script level.

Script management is not yet standardized in WoT, unless someone defines a WoT TD + service for that.

[mlagally]

The terminology section of WoT Architecture defines a servient:
A Servient can host and expose Things and/or host Consumers that consume Things.
It does not impose or constrain any implementation methodology, i.e. there may be limited servients that are only hosting one thing, or multi-thing servients.
Management of servients will be considered in the next phase of the WG as part of the lifecycle.

[relu91]

Thank you @mlagally and @zolkis for your answers. However, I have further considerations on this topic. First, I'll do my best to specify a little bit better the two scenarios described above: single application vs hypervisor.

Single application

In case of a single application if I want to run multiple applications on my host I should have the following situation:

Which is quite typical nowadays (see JVM, Python, Node etc.). In this implementation, I find difficult to understand the benefits to implement start or stop script functionalities. Because it is obvious that to start/stop a script means to start/stop the servient itself.

Hypervisor

Otherwise, in the hypervisor scenario the same situation looks like the following:

That's more similar to what a browser or a docker hypervisor do. On this implementation, start and stop are core functionalities that allow the servient to used in the real world.

Questions

Is there any consensus about this issue in the community? if not, will it be addressed in the next phase? or is it considered an implementation detail?

[mlagally]

Arch call on Oct 20th:
Agreed to close answered questions