To solve #14

[corbane]

[corbane]

Hello, Note that I did not test with neutralino.js in a WebWorker.

[shalithasuranga]

Hello... @corbane Thanks for the PR, if you have some time, will you be able to set up a web worker and test? Regarding #14 I think, app devs always need to use it as a normal browser script for reasons like,

• Client library doesn't do anything heavy to migrate to a web worker.
• Client lib uses DOM, so those API will fail inside the web worker.

Probably I can mention these things in the issue ;)

[corbane]

Hello @shalithasuranga ,

It's just a painless solution. And I don't have any use for using Neu inside a worker either. Maybe if Danidre14 explained the use, I would help to do a test.

[danidre14]

Hi @corbane yes I have a special use case as I commented in the other issue.

TLDR: For autosave backup files that aren't affected by the single-threaded JS.

I am working on a game engine editor software for my own game engine; it is similar to Adobe Flash Professional or Wick Editor. It involves adding flevaclips (prefabs/textfields), graphics, audio, as well as applying scripts for the flevaclips. The main necessity is the "Test" function. It opens a new window with the "compiled/transpiled" JS code of the game.

However, with this, since the test file was opened on the same thread as the editor, any blocking code (an infinite while loop the user uses, which is only detected at test/run-time) will freeze and crash even the editor, so users may lose data.

Thus, I have implemented an autosave function that uses webworkers to autosave progress every 30 seconds. Therefore, even if the user runs an infinite while loop and crashes the editor, when the kill the application and reopen it, they have the option of retrieving the last autosaved file (since the web worker works on a different thread)

For saving, I have created my own storage API that either uses the localstorage or indexeddb driver behind the scenes. When adapting the application to use Neutralino, I added the Neutralino storage APIs as an existing driver, so that the files are stored in the neu storage files instead. My custom storage API is also sent to the web worker (because in teh browser version indexeddb works in webworkers so I can still autosave). However, in the Neu application I was unable to use autosave without a hacked version of the Neu file which I outlined above.

That is why I proposed allowing the client lib inside a web worker...or at least, the storage part of it.