Closed chrisdickinson closed 1 year ago
@chrisdickinson thank you very much for the thorough review
that synchronous httpRequest is a killer for prod use; we should think about running the plugin in a Worker so we avoid gumming up the main thread
Yup, I agree. Unfortunately, I wasn't able to find any non-blocking ways. Your help would be greatly appreciated.
Great work on this – I'm closing this as complete, with work to continue in #7!
@bhelx asked me to take a quick look at the API to see how it maps to JS idioms. This is the result of a quick look – so there's probably stuff I've misunderstood about the implementation, apologies! I'd be happy to talk about any of these items more (or pitch in myself!)
async createPlugin(plugin, options): Plugin
as the default exportawait ExtismPlugin.new()
construction workable, but a little surprising! Usually there's a free-standing top-level export for asynchronous object creation alongside a constructor that can be used when you have all of the required info available synchronously. (Comparefs.Stats
tofs.stat(file, cb)
in Node.){path: string}
|{url: string}
.new URL
(which acceptsfile:///
-style URLs), then pass the resulting URL tofetch
– unifying the path/url casenpm.im/<package name>
to quickly get an idea of how to use a packageextism
is available, so we should grab that package name as wellhttpRequest
is a killer for prod use; we should think about running the plugin in aWorker
so we avoid gumming up the main threadhttpRequest
is a good argument for running the plugin inside a worker and adding faux "blocking" toextism_http_request
. We could makeextism_http_request
look "blocking" by sending aSharedArrayBuffer
from the worker to the main thread and using that to communicate response data back to the worker.