[whatwg] Global Script proposal.
michaeln at google.com
Wed Aug 19 13:50:45 PDT 2009
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller <pmuellr at muellerware.org>wrote:
> Dmitry Titov wrote:
> The return value from a constructor is the Global Script's "global scope
>> object". It can be used to directly access functions and variables defined
>> in global scope of the Global Script. While this global scope does not
>> 'window' or 'document' and does not have visual page associated with it,
>> local storage, database, timers and XHR are exposed to it, and it can
>> up DOM for the connected pages using their 'document' object.
> This turns out to be fairly similar to the serverJS concept of "modules".
> I could see how you might want to use it this way, to get script code
> loaded into it's own sandbox, and allow the client of the "module" to name
> the object as they see fit.
> This would require the use of a name when you create it, so as to allow
> multiple to be created, and to allow other sharers to find those objects.
> This also allows folks to programmatically load JS code without having to
> resort to XHR/eval or adding <script> nodes to the DOM. Big plus, because
> those scripts will then be associated with an honest-to-gods name, which
> will show up in debuggers. And is obviously cleaner than the other
> The list of
>> interfaces exposed in the global scope of the Global Script is similar to
>> that of Shared Worker, except message-passing interface. It could also
>> include events fired when a page connects/disconnects to it and before it
> Can I create additional GlobalScript's from within an existing
That's a good question...
(just having fun... oh the tangled web we weave;)
I'm not sure any has thought thru the implications of that, but it's an
* An obvious complication is life-cycle management. If GlobalScriptA
attaches to GlobalScriptB, when no 'pages' are attached to either, they
should be eligible for destruction.
* Also about tangled webs... what if A attaches to B, and B attaches to A
> The load() method is very similar to the worker loadScript() (or whatever)
> function. Perhaps we should combine them into one API, that allows sync or
> async in a worker, but only allows async in a GlobalScript. Or at least
> advises against use of sync.
> Patrick Mueller - http://muellerware.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg