- From: Patrick Mueller <pmuellr@muellerware.org>
- Date: Wed, 19 Aug 2009 16:34:33 -0400
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
Received on Wednesday, 19 August 2009 13:34:33 UTC