[whatwg] Global Script proposal.

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