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
