<br><br><div class="gmail_quote">On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller <span dir="ltr"><<a href="mailto:pmuellr@muellerware.org">pmuellr@muellerware.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Dmitry Titov wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The return value from a constructor is the Global Script's "global scope<br>
object". It can be used to directly access functions and variables defined<br>
in global scope of the Global Script. While this global scope does not have<br>
'window' or 'document' and does not have visual page associated with it, the<br>
local storage, database, timers and XHR are exposed to it, and it can build<br>
up DOM for the connected pages using their 'document' object. <br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
<br>
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.<div class="im">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The list of<br>
interfaces exposed in the global scope of the Global Script is similar to<br>
that of Shared Worker, except message-passing interface. It could also<br>
include events fired when a page connects/disconnects to it and before it is<br>
terminated.<br>
</blockquote>
<br></div>
Can I create additional GlobalScript's from within an existing GlobalScript?<br></blockquote><div><br></div><div>That's a good question...</div><div><br></div><div>(just having fun... oh the tangled web we weave;) </div>
<div><br></div><div>I'm not sure any has thought thru the implications of that, but it's an interesting idea.</div><div><br></div><div>* 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.</div>
<div><br></div><div>* Also about tangled webs... what if A attaches to B, and B attaches to A</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<div>
<div></div><div class="h5"><br>
<br>
<br>
-- <br>
Patrick Mueller - <a href="http://muellerware.org" target="_blank">http://muellerware.org</a><br>
<br>
</div></div></blockquote></div><br>