[whatwg] Global Script proposal.

[Patrick Mueller]

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
> terminated.

Can I create additional GlobalScript's from within an existing 
GlobalScript?

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