Closed rekmarks closed 2 years ago
For Snaps that need something like long-running workers, we may eventually introduce a concept of "workers" that are shipped as separate bundles with relaxed runtime limitations. For now, we will probably permit or openly support abusing the event-based model to facilitate long(er)-running snaps.
I've done some research into this previously.
eval
, to load the exports, second time to run the exported function. The logic would stay very similar to how we currently execute snaps using wallet.registerRpcMessageHandler
. That's also how it's done in other projects - 1, 2endowment:long-running
permission is encountered - the Snap would run in a special environment - a separate WebWorker with no timeouts.async-mutex
to synchronise storage reads and writes.
Currently, Snaps do not export anything, and communicate with the outside world by passing an RPC handler function to
wallet.registerRpcMessageHandler
. Their lifecycle is tied to this RPC message handler function, which is invoked every time the Snap receives some message.Rather than being plain scripts, we have decided that Snaps should export their RPC message handler function, which will be analogous to C's
int main()
. This handler function will be invoked every time the Snap receives a message, which may be RPC calls from external entities, or requests or events emitted from MetaMask itself. With the exception of talking to the network, the Snap will only be able to communicate with non-MetaMask subjects by returning values from its main function.With this refactor, Snaps will be event-driven both as a practical matter and in the structure of their code. The main function will receive an extensible object parameter, and will offer a more ergonomic developer experience for Snaps developers as opposed to the alternative. (Namely, slapping different functions onto the
wallet
object whenever we want to add a new message type.)Completing this refactor will entail:
Compartment.evaluate()
is called