[whatwg] Global Script proposal

Dmitry Titov dimich at google.com
Mon Aug 24 11:35:48 PDT 2009


I did mention 2 forms of script load indeed, mostly trying to find a
simplest form that will be also consistent with what's already there in the
spec.

In terms of loading scripts, it seems the GlobalScript is quite similar to
what SharedWorker does to load its scripts.When creating SharedWorker, one
specifies the url right away as a constructor parameter, and this url later
is used to form an ID of the SharedWorker. The load is asynchronous and the
page is registering an event handler to 'hear' from the script when it is
ready. The Worker can, in turn, create 'nested' Workers (async). Also, it
can load more scripts into themselves via importScript(urls) - this time
synchronously (this is rough equivalent of <script> tag in a JS context).
Note that initial load is different from 'importing' more script - initial
loading is governed by SOP and is async, while the importScript can go
cross-domain, does not create a security context and is synchronous.

Whether or not this is the best possible scheme is a separate topic, but it
seems close enough to what GlobalScript needs so if nothing else,
consistency with this spec might be a good idea.

Dmitry

On Mon, Aug 24, 2009 at 6:05 AM, Patrick Mueller <pmuellr at muellerware.org>wrote:

> Patrick Mueller wrote:
>
>> Michael Nordman wrote:
>>
>>> I'm confused about the manual loading of the script into the context? The
>>> original proposal called for providing a script url when
>>> creating/connecting
>>> to an instance of a global-script... in which case each client page
>>> expresses something more like...
>>> globalScript = new GlobalScript(scriptUrl);
>>> globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
>>> // some time later onload fires, if the script was already loaded, its
>>> called on the next time thru the message loop
>>>
>>
>> Here's what Dmitry Titov proposed on 2009/08/17:
>>
>>   var context = new GlobalScript();
>>   context.onload = function () {...}
>>   context.onerror = function () {...}
>>   context.load('foo.js');
>>
>
> 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.
>
>
> --
> Patrick Mueller - http://muellerware.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090824/c4037f69/attachment-0002.htm>


More information about the whatwg mailing list