[whatwg] Global Script proposal.

[Patrick Mueller]

Michael Nordman wrote:
> On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller <pmuellr at muellerware.org>wrote:
>> Can I create additional GlobalScript's from within an existing
>> GlobalScript?
> 
> That's a good question...
> 
> (just having fun... oh the tangled web we weave;)
> 
> I'm not sure any has thought thru the implications of that, but it's an
> interesting idea.
> 
> * 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.
> 
> * Also about tangled webs... what if A attaches to B, and B attaches to A

For completeness, folks interested in this proposal should probably 
check out the serverJS Securable Module stuff:

	https://wiki.mozilla.org/ServerJS/Modules/SecurableModules

There are similarities, and differences:

- In serverJS, modules are identified with a JavaScript resource, 
presumably a single one.  In Shared Scopes (what I'm going to call 
Global Script from here on in), modules are identified with just a name 
and code is loaded through a different path.  I like the Shared Scopes 
version better, more flexible.

- In serverJS, module loading may need to be done in a careful order so 
that "pre-req" modules are loaded before the modules that pre-req them 
(ie, require() them).  That's because there is code running while the 
module is being defined.  If we end up having all the shared scopes 
available via their name in every shared scope and page that are 
attached to each other, I don't think there's a problem.  Creating a new 
scope is atomic operation, no user-land code runs as a result.  No doubt 
folks will be writing guarded code to ensure they only load scripts into 
a SharedScope once, since the code loading is now a separate issue. 
Again, I like the Shared Scopes approach better.

- In serverJS, a module does not export it's global variable to the 
client.  Instead, when the module code is run, the object which will 
eventually be returned from require() is set to the variable "exports" 
in the module code.  In Shared Scopes, this additional level of 
indirection is not available; "global" variables set in code run in the 
context of the SharedScope are the properties of the object returned 
from the SharedScope accessor.  In this case, I prefer the serverJS 
style.  It makes it clear in the module code what you actually want the 
client to have access to.  It also lets you hide private variables 
inside your own global environment, which is visible to no one.  The 
same way variables are typically hidden in a function closure today. 
Imagine, maybe you won't have da funky function wrappers anymore!

     (function(){
         ... my code here
     })();

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

I think the API I was thinking of with workers is 
importScripts(url,url,urls).  It seems crazy to have different ways to 
do basically the same thing, whether you're in a worker or not.  There 
should probably be one API to "load and run a script", that could be 
used sync or async (user controlled just like XHR), with callbacks etc.

Time to work on some examples.  This would relatively easy to prototype 
in something like Rhino (or my nitro_pie python wrapper for 
JavaScriptCore), at least API wise, so we could see what the user-land 
code would look like, and see it run.

-- 
Patrick Mueller - http://muellerware.org