[whatwg] Global Script proposal

[Sigbjorn Finne]

Hi,

a general comment on the interesting GlobalScript proposal for helping
to structure client-side portions of a web application - have people looked
in detail at existing work & experiences made there? Like .NET's AppDomains.

cheers
--sigbjorn (sof at opera.com)

On 8/21/2009 21:47, Michael Nordman wrote:
> I'm confused about the manual loading of the script into the context? The
> original proposal called for providing a script url when creating/connecting
> to an instance of a global-script... in which case each client page
> expresses something more like...
> globalScript = new GlobalScript(scriptUrl);
> globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
> // some time later onload fires, if the script was already loaded, its
> called on the next time thru the message loop
>
>
> ... the system (not the client pages) keep track of how many client pages
> are concurrently accessing the same GlobalScript.
>
> 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.
>>
>> --
>> Patrick Mueller - http://muellerware.org
>>
>>
>>     
>
>