- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Fri, 21 Aug 2009 12:27:30 -0700
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>
Received on Friday, 21 August 2009 12:27:30 UTC