[whatwg] Global Script proposal.
pmuellr at muellerware.org
Wed Aug 19 13:34:33 PDT 2009
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 have
> 'window' or 'document' and does not have visual page associated with it, the
> local storage, database, timers and XHR are exposed to it, and it can build
> 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 techniques.
> 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 is
Can I create additional GlobalScript's from within an existing
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
More information about the whatwg