[whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
aa at google.com
Thu Feb 14 17:44:24 PST 2008
On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> > Since postMessage API is looking more an more like the Gears worker
> > messaging API (or better), can we go one step further and introduce
> > workers into the HTML5, defined as invisible windows with limited
> > capabilities:
> Why call these "windows" at all? They seem to have no relationship
No relation. It might be easier for some developers to get it if
associated with the window. I think it's a bit of a rough metaphor
myself, and did not call the object Window in my proposal, but
> > WorkerWindow openWorker(in DOMString url);
> Can I supply a URL to an HTML file here? Does the file load and parse
> as an HTML document? Is the document accessible to the worker?
> this string be a script instead of a URL?
This is how Gears used to work and it was very inconvenient. Web apps
do not really have access to their source code as a string
conveniently. They could use XHR to request a script file and then
send it into the worker,but why make them do this?
> How do I pass data to a worker?
Please see either Ian's or my proposal earlier in this thread for an
example of how this could work. Basically, like postMessage().
> Is there an API contract regarding synchronization and/or order of
I think that the API should guarantee that the script is executed on
another thread. I don't think that the API should guarantee that
anything has happened when createWorker*() returns, as UA's will want
to load the script file asynchronously.
However, I think that developers should be able to start sending
messages to workers immediately, before the worker has loaded. These
messages should be queued and delivered when the worker loads.
More information about the whatwg