[whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)

Dimitri Glazkov dimitri.glazkov at gmail.com
Fri Feb 15 07:00:46 PST 2008


These are all good questions.

I apologize, this was a spur-of-the-moment
write-down-before-it-goes-away post. And as such, it's skimp on the
meat. If anything, it was a good enough nudge for Aaron and Hixie to
release their proposals.

What I did want to capture is the idea of API familiarity to that
could exist inside of a worker, so that the developers operate with
the same (though a subset of) methods and properties as they would
outside of the worker and use the same postMessage API to communicate
with the workers as they would with other windows.


On Thu, Feb 14, 2008 at 5: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
>  physical windows, or the JavaScript "window" object.
>  > 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?
>  Since the whole point of the worker is to do JavaScript work, should
>  this string be a script instead of a URL?
>  How do I pass data to a worker?
>  Is there an API contract regarding synchronization and/or order of
>  execution?
>  >   // some events
>  >   attribute EventListener onabort;
>  >   attribute EventListener onload;
>  >   attribute EventListener onunload;
>  Why these events?
>  When is a worker considered loaded? Unloaded? Aborted?
>  Thanks,
>  Geoff

More information about the whatwg mailing list