- From: Patrick Mueller <pmuellr@muellerware.org>
- Date: Wed, 19 Aug 2009 10:37:28 -0400
This looks interesting. Dmitry Titov wrote: > > A web page will be able to create a Global Script and connect to it, as in > this example: > > var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as > experimental feature? > context.onload = function () {...} > context.onerror = function () {...} > context.load('foo.js'); Presumably this script is being loaded asynchronously, hence the callbacks. But since the GlobalScript() constructor returns the "global" object, probably doesn't make sense to attach the handlers directly there, but actually on the load request somehow. And presumably you'd be able to load multiple .js files. This will be interesting, as the .js files presumably will get interpreted in an arbitrary order - we'll be inventing some new idioms (not a problem, just an observation). Is this then really the only API exposed? A constructor and a js loader? (+1, less is more) I guess I'm wondering if there will be some desire to have pages opt-in to this support, signaling this through an additional API, or like the app-cache's manifest attribute on the <html> element, something in the DOM; doesn't seem like we should drag the DOM in here, just mentioned it because I was reminded of the way the opt-in works there. Or perhaps these GlobalScripts - should really be called GlobalObjects or GlobalContexts maybe; SharedScope? - could be named, by passing a string on the constructor? Would there be value in having multiple named scopes available? In the current scenario with a no-arg constructor, what happens when I invoke it again? If it should return the same object, then don't use a constructor, use a plain old function - SharedScope.getCurrent(). -- Patrick Mueller - http://muellerware.org
Received on Wednesday, 19 August 2009 07:37:28 UTC