[whatwg] Global Script proposal.

Wed Aug 19 11:16:36 PDT 2009

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>