- From: Ian Kilpatrick via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Jun 2016 20:28:35 +0000
- To: public-houdini-archive@w3.org
Right, the original thought was to effectively split the algorithm into: (1) "fetch a module script tree resources" Takes the "url" to produce a tree of "url" - "script source text", this would need to explain that a JS engine could pre-process some source text to resolve and fetch all the required modules, without actually creating a script and binding it to a realm. This would be sort of steps 1-10 in "fetch a single module script" + fetching the tree. (2) Upon initializing a WorkletGlobalScope post this tree of "url" - "script source text" over. (3) "create a module script tree" Takes the script source tree and just realizes into actual scripts for the global. But this is pretty nasty :-) I like just having a cache on the `Worklet` object that fetch runs through, I think they achieve the same thing (I can't think of any side-effects that would be visible from spec'cing one way or another). As a side note, I've been stalking adamk's module work in v8 and it looks like we'll be able to create an "UnboundModule" in v8 which means we can analyze what we need to fetch early on potentially, and be able to do something similar to the first option internally. I'll sync up with him when i'm in SFO next. -- GitHub Notification of comment by bfgeek Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/229#issuecomment-228453986 using your GitHub account
Received on Friday, 24 June 2016 20:28:38 UTC