- From: Dimitri Glazkov <dimitri.glazkov@gmail.com>
- Date: Fri, 15 Feb 2008 09:00:46 -0600
Geoff, 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. :DG< 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 >
Received on Friday, 15 February 2008 07:00:46 UTC