- From: Sigbjorn Finne <sigbjorn.finne@gmail.com>
- Date: Fri, 21 Aug 2009 22:13:52 +0200
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 >> >> >> > >
Received on Friday, 21 August 2009 13:13:52 UTC