Agreed, blocking semantics are definitely not OK for GlobalScript, this context-type calls for some form of async importScript functionality. If order load order matters, apps certainly could defer loading the scripts until what they depend on have been already loaded already. Where load order doesn't matter, seems unfortunate to penalize those callers.<div>
<br></div><div>Maybe</div><div><span class="Apple-style-span" style="font-family: sans-serif, 'Droid Sans Fallback'; font-size: medium; line-height: 21px; "><pre style="margin-left: 2em; white-space: pre-wrap; font-size: inherit; font-family: monospace, 'Droid Sans Fallback'; font-variant: normal; ">
importScripts(['one.js', 'two.js'], onloadcallback, onerrorcallback);</pre><pre style="margin-left: 2em; white-space: pre-wrap; font-size: inherit; font-family: monospace, 'Droid Sans Fallback'; font-variant: normal; ">
Immediately initiates in-order loading of the given array of resources. A second call to importScripts would also begin immediately as well. So if order matters, put them in the same importScripts call, and if it doesn't make individual calls.</pre>
</span><br><div class="gmail_quote">On Mon, Aug 24, 2009 at 3:15 PM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com">atwilson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
BTW, the WorkerGlobalScope.importScript() API blocks the current thread of execution, which is probably not acceptable for code executed from page context. So for globalscripts we'll need some way to do async notifications when the loading is complete, and report errors. We may also want to have some way to automatically enforce ordering (so if I call GlobalScript.importScripts() twice in a row, the second script is not executed until after the first script is loaded/executed, to deal with dependencies between scripts). The alternative is to force applications to do their own manual ordering.<div>
<div><br></div><div>-atw<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Mon, Aug 24, 2009 at 11:32 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br></div></div>
Dmitry had a later note which combined creation of the context and loading of the script. But I suspect one thing people will want to do, in development anyway, is load multiple scripts into a context - like you can in workers. Which would mean we'd still need a function to load a script, or the only way to load a script would be by also creating a new context - which is much like the serverJS module concept.</blockquote>
<div><br></div></div><div>I think the plan is to provide an importScript(...) function to globalScripts as is done for workers...</div><div><a href="http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries" target="_blank">http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries</a></div>
</div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>