search

eclipse-thingweb / node-wot

Components for building WoT devices or for interacting with them over various IoT protocols
https://thingweb.io
Other
161 stars 78 forks source link

[question] Is there any plan for a stopScript action? #155

Open hyperloris opened 4 years ago

hyperloris commented 4 years ago

Hi, I recently had the need to stop a running script. Digging inside the code I realized that such functionality is not yet implemented, so I was wondering if there is any plan to add this in the near future and if you have already thought how to do that.

I think that the stop of a script should:

wiresio commented 4 years ago

It would be great to have such functionality in node-wot. The best point to start is probably packages/cli/src/cli-default-servient.ts. Please feel free to come up with a PR.

relu91 commented 4 years ago

Hi all, after my latest PR (see #129), @hyperloris and I talked a lot about how to improve WoT script life cycle and management. We would be glad to start working on this new feature, but first, I would like to discuss with the community about a couple of things.

Currently, scripts are not actually "runned" but they are "evalueted". This means that the caller have no mean to control the computation or stop it. An example is that the VM module of nodejs does not offer any API to "stop" script computation but only to run them (see here. A solution would be to embed the computation in subprocesses or in Wokers threads (which I prefer cause they are more lightweight). Therefore, following this solution it will result in: one script -> one thread. Stopping one script in this scenario would mean to:

  1. clean resources (i.e. action/property/event handlers, produced things ...
  2. stop the thread associated with it

What do you think?

zolkis commented 4 years ago

FWIW the start() and stop() were part of the ExposedThing API object not long ago. If there is a need for that, we could re-discuss, please file an issue at WoT Scripting API.

relu91 commented 4 years ago

I've just checked the WoT Scripting API document and it seems that the destroy method fits pretty well with point 1. However, it seems that is not yet implemented in node-wot (check here ). Therefore, we could start from there. Thanks, @zolkis for the hint! However, I still think we should consider more closely the role of scripts inside the WoT runtime. Like if they are also a first-class entity 🤔

zolkis commented 4 years ago

We will likely discuss scripts lifecycle in Scripting calls starting in January. Welcome to attend them on Mondays 1pm CET.

Indeed, there are 2 ways to approach this, starting from a Thing and a script.

  1. Right now a TD specifies one Thing, so a Thing is a first class entity. In addition to a TD, developers can augment Thing functionality by using a script that uses the Thing interactions (ConsumedThing), or defines the Thing interactions (ExposedThing). One of the main use cases being composability, i.e. using multiple ConsumedThing to define a new ExposedThing. Since the Thing gets bindings etc, I would find it useful to have a start() and stop() method, at least with ExposedThing, which would denote starting and stopping the service in the local OS. However, the need has been contested because an overlap was sensed with expose() and destroy(), so we merged them until developers ask for re-opening the discussion.

  2. The infrastructure to deploy a script depends on the deployment environment. Currently we can use npm, i.e. one writes a script and package in Node.js. We can also deploy scripts directly with node-wot.

In the future I'd like if the group would investigate using WebAssembly modules as an alternative mechanism for WoT scripts. This would have multiple advantages: the same code (of multiple supported source languages, including TypeScript) could eventually run both in the browser and in a headless environment. However, that depends on the WASI development. The challenge is to find a good abstraction API to cover WoT dependencies. For instance, a sensor API has been planned for WASI (for instance it could be based on the W3C Generic Sensor framework). In addition, likely only https and coaps should be needed. Nowadays COAP is supported even in very constrained platforms (e.g. Zephyr OS).

We need to do proofs of concept for these use cases of Thing and script deployments. Help would be greatly appreciated.

relu91 commented 4 years ago

Hi @zolkis, sorry for the huge delay and thank you very much for your invitation to the calls. Unfortunately, I don't think I will be able to attend them any time soon 😞.

I think that WebAssembly has a lot of potential inside the WoT environment. Therefore, I agree with you that this solution should be at least evaluated and taken into consideration for scripts.

We may do some experiments with it in the near future, I'll keep you and the community informed of the results.