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 <[email protected]>
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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
