- From: Michael Nordman <michaeln@google.com>
- Date: Wed, 19 Aug 2009 11:16:36 -0700
On Wed, Aug 19, 2009 at 10:48 AM, Dmitry Titov <dimich at google.com> wrote: > On Wed, Aug 19, 2009 at 7:37 AM, Patrick Mueller <pmuellr at muellerware.org>wrote: > >> 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. > > > Good point. Alternative variant to construction/connection to this object > could be something like this: > > window.createGlobalScript('name', 'foo.js', function(context) {..}, > function(status) {..}); > > where the name and url pair play the same role as on SharedWorker, and 2 > callbacks: one delivers load status/errors, another comes with resolved > context when it's ready. One benefit of this is that 'context' does not have > to expose the 'external' API on it and it is always functional once it's > returned. The syntax in the proposal was motivated by commonality with other > APIs, like XHR or window.open - however I agree this doesn't fit 100% either > of them... > fyi: There's a seperate thread questioning the utility of the 'name' parameter in the SharedWorker API. However the debate ends, it would probably be good to identify shared-workers / global-scripts in a similar fashion. > 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. >> > > I don't follow the opt-in desirement? If a page wishes to utilize the GlobalScript feature, it calls the API provided to do so. > It is a good idea indeed to have some sort of static opt-in information, > maybe via a feature of app-cache - which could hint the UA to load > participating pages (of the same application) into the same process so they > could share Global Script. It is still impossible (and probably not > important) to guarantee a singularity of the Global Script (as in case of > cross-domain iframes) but it'd be a good optimization for a multi-process > UA. > I understand the desire for early warning that a page *may* want to utilized a GlobalScript. A 'hint' could be useful to a multi-process UA. It's not clear to me that this is what Patrick was referring to... Patrick? And I'll just throw out there that a 'hint' in an custom HTTP header of the page's response would be the earliest warning we could get without static config info present in the UA. I know Ian doesn't like relying on out-of-band HTTP things for the HTML5 spec... just sayin... > > Dmitry > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090819/0bcb3bad/attachment.htm>
Received on Wednesday, 19 August 2009 11:16:36 UTC