Showing content from https://github.com/openpgpjs/openpgpjs/issues/964 below:
Remove the Worker · Issue #964 · openpgpjs/openpgpjs · GitHub
It is better to have a worker in the application, than in a library, for a variety of reasons:
- Currently, an application that uses the worker has to load OpenPGP.js twice, once in the main thread and once in the worker. This is unnecessary and inefficient. ( openpgpjs loaded twice into memory? #839)
- Having the worker inside OpenPGP.js prevents tree shaking, since the worker script does not know in advance which functions of OpenPGP.js it will be asked to call. Having the application's workers script call OpenPGP.js directly makes that information known.
- Having only the application import OpenPGP.js (rather than having our worker script import it as well) would allow the application to use their own build process and treat OpenPGP.js as a normal ES6 module.
- Parsing and storing keys inside the worker (instead of in the main thread as is currently done) would allow us to cache certain information that we currently have to calculate in the worker each time the key is used. It would also avoid having to copy the key to the worker each time, and further offload work from the main thread while parsing.
- Similarly, the application could fetch keys and messages from their server directly inside the worker, further reducing copying. This is particularly useful when stream-decrypting a message.
- It would allow us to add callback hooks, or allow the application to monkey-patch functions in OpenPGP.js.
There are also some challenges:
- Obviously, application developers have to create this worker. Removing it from OpenPGP.js makes it more difficult for developers to get started with the library in the most efficient way possible. We could write some "getting started" example code that creates a worker.
- When stream-decrypting a message; OpenPGP.js currently passes the data to the main thread chunk by chunk. Applications might have to re-implement this, due to can streams be transferred via postMessage()? whatwg/streams#276. Alternatively, applications could use OpenPGP.js inside a Service Worker; and rely on Response's streaming support to pass the data to the application (or a file).
For stream-encrypting, the most common use case is probably encrypting a File
object, which can be passed using postMessage
.
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4