[whatwg] Global Script proposal

[Patrick Mueller]

Patrick Mueller wrote:
> 
> 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.

I developed a simulator for this yesterday.  My big take away is that 
the current shape leaves users in a batteries-not-included state.

Here's the kind of code I had to write to arrange to create a new scope 
and load a single script in it from multiple windows.  Each window would 
run this code in it's own context.

function loadLibrary(scopeName, script, callback) {
     var scope = getSharedScope(scopeName);

     // script already loaded in the scope
     if (scope.__loaded) {
         callback(scope, scope.__callback_data);
     }

     // script not yet done loading
     else if (scope.__loading) {
         scope.__onLoadedListeners.push(callback);
     }

     // first one in!  much work to do ...
     else {
         scope.__loading = true;
         scope.__onLoadedListeners = [];

         function handler(callback_data) {

             scope.__loaded        = true;
             scope.__loading       = false;
             scope.__callback_data = callback_data;

             callback(scope, callback_data);
             for (var i=0; i<scope.__onLoadedListeners.length; i++) {
                 scope.__onLoadedListeners[i](scope, callback_data);
             }
         }

         scope.runScript(script, {handler: handler});
     }

     return scope;
}

I changed the GlobalScript() constructor to a getSharedScope() function 
(at the top), and the load() function to a runScript() function which 
takes parameters including a callback function.

I'm of two minds here.

One is that the SharedScope proposal is really only appropriate for 
pages with lots of JavaScript that could be shared, or special use cases 
where you want (eventually) easy sharing between windows.  As such, s 
smallish amount of JS framework-y-ness like this isn't a show stopper. 
In fact, as spec'd, separating out the scope and script loading, will 
let folks build mini-frameworks for themselves fairly easily, customized 
to their own needs.

On the other hand, I wonder about the potential benefits of letting more 
people play in the space easier.  The securable module work in the 
serverjs projects it a bit easier to use out of the box.  I'm not sure 
they have an async story though, and async loading of scripts is where 
this stuff quickly gets complicated.

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