[webkit-dev] GlobalScript API.

[Alex Russell]

On Tue, Sep 1, 2009 at 9:58 PM, Ojan Vafai<ojan at chromium.org> wrote:
> On Tue, Sep 1, 2009 at 9:07 PM, Oliver Hunt <oliver at apple.com> wrote:
>>
>> On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:
>>
>> Thanks a lot Maciej!
>> As a note to the API described in this thread: there was a proposal in
>> private thread to replace the JS constructor with 4 parameters with a tag:
>> instead of
>> var globalScript = new webkitGlobalScript(name, url, loadHandler,
>> errorHandler);
>
> I know this as been discussed a million times already, but this bugs me.
> What if you want to load multiple scripts or populate a globalscript from
> the parent page(s)? I prefer the other importScript-like ideas.
> I'd much prefer if we made creating a globalScript synchronous and with no
> network request. The async load of iframes with an empty src is really
> frustrating to web developers and causes lots of bugs and performance
> problems in practice.
> If we keep this syntax, we should at least try and special-case leaving out
> the url argument so that we load the globalscript synchronously. I'm not
> sure if this is really feasible given the time it takes to create a
> Document, but we should at least try it and measure the performance..

Not to harp, but for lack of a missing abstraction (Deferreds or
Futures, or whatever your particular CS dept called them), we've seen
every JS library on the planet re-invent some "onready" abstraction
when the built-in events don't quite cover it. This is just another
place where having a uniform for way to listen for a single event
(which possibly already happened) would turn this into a simpler
problem.

Something like:

var globalScript = new webkitGlobalScript(name);

// ...time/flow control passes...

globalScript.onready(handler);

// ...time passes....

globalScript.src = "....";

// ...time passes, ready happens....

// handler is called immediately on registration since future already arrived.
globalScript.onready(anotherHandler);

Regards

>> to have this:
>> <webkit-globalscript name='...', src='url', onload=...
>> onerror=...></webkit-globalscript>
>>
>> This actually displays one of the issues i have with global script as a
>> concept, you are basically just doing
>> <iframe src="..."></..>
>> And that gives you a context that achieves almost everything the global
>> script concept gives you.
>
> People keep saying that this is no better than a new window or an iframe
> because you can script those synchronously across pages, but that totally
> misses the point. The the frame/script/window survives when it's parent page
> is closed if there's another page pointing to it and, in some versions of
> this proposal, it survives same-origin page navigations. That isn't true of
> iframes or windows and is exactly what makes these useful.
> For the record, I'm on the fence about this idea, but it seems worth
> experimenting with if there are web pages that will follow through with
> using them, understanding that they're experimental APIs of course.
> Ojan
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>