[webkit-dev] GlobalScript API.

Tue Sep 1 20:07:46 PDT 2009

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);
>
> to have this:
> <webkit-globalscript name='...', src='url', onload=... onerror=...></ 
> webkit-globalscript>
>
> The first tag with a specific name that provides a src or inline  
> script or injected with innerText would effectively supply 'initial  
> script'. The later-encountered tags withthe same name would have  
> their initial script ignored and simply connected to the same one.  
> The tag's DOM element would be EventTarget (for load and error) and  
> have a 'context' property to pull the global scope object of the  
> script.

Why is a tag better for this than a constructor or function?

Regards,
Maciej

>
> Dmitry
>
> On Mon, Aug 31, 2009 at 7:18 PM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> On Aug 31, 2009, at 6:09 PM, Dmitry Titov wrote:
>
>> Hi WebKit-dev,
>>
>> I'm hoping to get your advice on Global Script proposal and how to  
>> start implementing it as an 'experimental API' since it's not  
>> standardized yet.
>>
>> As part of work on Workers in WebKit and Chromium, we discussed  
>> them with our web application folks (mostly gmail). We came to the  
>> idea that in addition to workers, they need a shared script context  
>> which runs on the same UI thread and directly scriptable.
>>
>> Our previous take (with an invisible window running all the time in  
>> the background) was not that fruitful but it indicated the way to  
>> go. We are thankful to the members of the whatwg community for the  
>> detailed threat analysis of 'permanently running invisible pages',  
>> it helped very much. Not right away but it was absorbed :-) Current  
>> proposal reflects realization that there is a less-powerful way to  
>> achieve the same benefits.
>>
>> I'm looking for a way to implement it as an experimental API in  
>> WebKit and Chromium. I'm thinking it can go the similar way as  
>> webkitNotifications - surrounded by ENABLE(GLOBAL_SCRIPT) and  
>> prefixed with 'webkit' to keep the difference.
>
> Here's what I think we should take a look at:
>
> 1) Does this proposal have a potential standards-track future?  
> Relevant specific issues would be interest from other browser  
> vendors and standards folks, interest from content producers, and  
> our own degree of confidence that this is the right approach. Note:  
> in some cases a prototype can be the best way to address concerns,  
> however. In some cases we're willing to add proprietary extensions  
> that have little hope of ever becoming a standard, but almost always  
> we do this for the sake of non-browser use.
>
> 2) Do we have some agreement in the WebKit community that this is a  
> good approach? It would be good for us to do some of our own design  
> review, if this isn't going to be a standard in the foreseeable  
> future.
>
> If we are optimistic about the future, then an ENABLE macro and a  
> WebKit prefix would be a good way to handle things.
>
> I will do some detailed design review soon.
>
> Regards,
> Maciej
>
>>
>> I'd appreciate much your advice on the whole API and on the way to  
>> bring it into WebKit.
>>
>> Here is a link to the whatwg thread, with the proposal and use  
>> cases: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html
>>
>> Here is an actual API:
>> ---------------------------
>> Page-level API
>>
>> var globalScript = new webkitGlobalScript(name, url, loadHandler,  
>> errorHandler);
>>
>> This returns a global scope object for the named Global Script.
>> If one does not exist yet, creates a new one. The globalScript is
>> sharing same process and same thread as the page running the  
>> constructor
>> and is operational right away. No synchronization is necessary.
>> Parameters:
>> name - string identifying the global script. Scoped to the orogin.
>> url  - the JS resource to load, if it was not yet loaded. If the  
>> Global Script is already loaded but from a different url - the  
>> error is raised.
>> laodHandler - a function called asynchronously when the script is  
>> loaded (or if it was already loaded by another page)
>> errorHandler - handler for loading errors, like violation of same- 
>> origin policy or network error
>>
>> The GlobalScript would create its own ScriptExecutionContext- 
>> derived context if it was not yet created, and start to load the  
>> script into it. Once the script is loaded, it is evaluated in the  
>> global scope of the Global Script and loadHandlers are executed.  
>> Other pages that create a Global Script with the same name in the  
>> same origin would get the same object back.
>>
>> The globalScript object returned from the constructor can be  
>> immediately used to set/retrieve properties and event handlers on it.
>>
>> API exposed to Global Script (on its global scope object)
>> - Timers
>> - XHR
>> - Navigator
>> - localStorage
>> - Database
>> - Workers
>> -----------------------------
>>
>> Thanks,
>> Dmitry
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090901/ac12d1ce/attachment.html>