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 (s...@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 <pmue...@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
