[whatwg] Global Script proposal

[Jeremy Orlow]

On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller <pmuellr at muellerware.org>wrote:

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


For a feature of this scope, I think it's much better to keep the API
surface area as low as is possible for the first version.  If, out of the
frameworks, emerges a clear winner, then we should talk about expanding the
API.  Until then, I worry we'll just be speculating/bike-shedding.

Thanks for doing this, btw!

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090821/67130228/attachment.htm>