Re: [whatwg] Workers in HTML5
On Wed, Feb 20, 2008 at 3:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: If XMLHttpRequest is one of the APIs available on background threads, does that include its XML parsing/serialization features (responseXML and the ability to pass a Document as the post data)? If so, then effectively the whole DOM API has to be available on the background thread, which may increase the implementation complexity a fair bit over having only selected APIs available. Having the DOM be available on other threads would be a pretty big implementation burden for us too. Then there are are DOM APIs like canvas, SVG APIs, etc ... each of those would either have to be disabled on worker threads or take additional work to make thread-safe (even if the additional work is just checking code). There's also styles and subresource loading, which we already disable on XHR data documents but I'm not sure if that's defined in any spec. Basically this is a very big can of worms you're opening here... Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, Feb 14, 2008 at 5:44 PM, Aaron Boodman [EMAIL PROTECTED] wrote: On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen [EMAIL PROTECTED] 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. 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 WorkerContext. It seems to me that this is an area where if you give an inch, the developer wants another inch. If you have something called window, then you're just moving things around - instead of saying Where is my window?, developers get to say Why can't my window do X? Since this is all new ground, it might be more reasonable to define the set of things you want to have in your worker context, and then contrive to add those things to your UI context. That way you're explaining what is there, rather than excusing what is not there. [Anvil labeled Legacy Interfaces lands on Scott's head.] -scott
Re: [whatwg] Workers in HTML5
On Tue, Feb 19, 2008 at 2:58 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: Given that most people don't know the difference between the Window and the global object and the global worker object will already contain a bunch of APIs identical to those on the Window object it seems to me that giving the object and interface a different name doesn't really help. I'm not necessarily sold on making the worker context be the global object. I always thought having the Window object be the global object was a bit unfortunate, myself. What if we had separate objects: - the global scope (with all the typical JS globals, and maybe XMLHttpRequest) - workerContext (with all the worker stuff, plus cookies, location, etc) Thoughts? - a
Re: [whatwg] Workers in HTML5
On Tue, 19 Feb 2008 22:46:44 +0100, Scott Hess [EMAIL PROTECTED] wrote: It seems to me that this is an area where if you give an inch, the developer wants another inch. If you have something called window, then you're just moving things around - instead of saying Where is my window?, developers get to say Why can't my window do X? Since this is all new ground, it might be more reasonable to define the set of things you want to have in your worker context, and then contrive to add those things to your UI context. That way you're explaining what is there, rather than excusing what is not there. [Anvil labeled Legacy Interfaces lands on Scott's head.] Given that most people don't know the difference between the Window and the global object and the global worker object will already contain a bunch of APIs identical to those on the Window object it seems to me that giving the object and interface a different name doesn't really help. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Workers in HTML5
On Feb 19, 2008, at 2:57 PM, Aaron Boodman wrote: On Tue, Feb 19, 2008 at 2:58 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: Given that most people don't know the difference between the Window and the global object and the global worker object will already contain a bunch of APIs identical to those on the Window object it seems to me that giving the object and interface a different name doesn't really help. I'm not necessarily sold on making the worker context be the global object. I always thought having the Window object be the global object was a bit unfortunate, myself. What if we had separate objects: - the global scope (with all the typical JS globals, and maybe XMLHttpRequest) - workerContext (with all the worker stuff, plus cookies, location, etc) Thoughts? If XMLHttpRequest is one of the APIs available on background threads, does that include its XML parsing/serialization features (responseXML and the ability to pass a Document as the post data)? If so, then effectively the whole DOM API has to be available on the background thread, which may increase the implementation complexity a fair bit over having only selected APIs available. Regards, Maciej
Re: [whatwg] Workers in HTML5
On Tue, Feb 19, 2008 at 6:05 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: If XMLHttpRequest is one of the APIs available on background threads, does that include its XML parsing/serialization features (responseXML and the ability to pass a Document as the post data)? If so, then effectively the whole DOM API has to be available on the background thread, which may increase the implementation complexity a fair bit over having only selected APIs available. I think it should be spec'd with those features required. Gears probably won't implement the XML part initially. - a
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
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 [EMAIL PROTECTED] 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
[whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
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:
WorkerWindow openWorker(in DOMString url);
with:
interface WorkerWindow {
// for consistency with Window
readonly attribute Window window;
readonly attribute Window self;
// caps
readonly attribute ClientInformation navigator;
// session/local storage
readonly attribute Storage sessionStorage;
...
// database stuff
Database openDatabase(...)
// to open new worker windows
WorkerWindow openWorker(in DOMString url);
// messaging
void postMessage(...)
// some events
attribute EventListener onabort;
attribute EventListener onload;
attribute EventListener onunload;
}
or something like that?
:DG
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
Well, as long as you've brought it up, I was working on a proposal too:
http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal
- a
On Thu, Feb 14, 2008 at 11:34 AM, Dimitri Glazkov
[EMAIL PROTECTED] 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:
WorkerWindow openWorker(in DOMString url);
with:
interface WorkerWindow {
// for consistency with Window
readonly attribute Window window;
readonly attribute Window self;
// caps
readonly attribute ClientInformation navigator;
// session/local storage
readonly attribute Storage sessionStorage;
...
// database stuff
Database openDatabase(...)
// to open new worker windows
WorkerWindow openWorker(in DOMString url);
// messaging
void postMessage(...)
// some events
attribute EventListener onabort;
attribute EventListener onload;
attribute EventListener onunload;
}
or something like that?
:DG
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
LOL. Who else has been quietly concocting a worker spec? This very much along the lines of what I was thinking. Equating worker to (or drawing parallels with) a window object is the approach that would make workers easier to understand for developers, IMHO. I am not quite sure yet about DOM access/interaction. On 2/14/08, Ian Hickson [EMAIL PROTECTED] wrote: On Thu, 14 Feb 2008, Aaron Boodman wrote: Well, as long as you've brought it up, I was working on a proposal too: http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal As was I. :-) http://www.hixie.ch/specs/dom/workers/0.9 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
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
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, Feb 14, 2008 at 11:34 AM, Dimitri Glazkov [EMAIL PROTECTED] wrote: // caps readonly attribute ClientInformation navigator; I forgot about navigator in my proposal. That is another one that has been asked for in Gears workers. Added! - a
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, 14 Feb 2008, Aaron Boodman wrote: Well, as long as you've brought it up, I was working on a proposal too: http://code.google.com/p/google-gears/wiki/HTML5WorkerProposal As was I. :-) http://www.hixie.ch/specs/dom/workers/0.9 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)
On Thu, Feb 14, 2008 at 3:05 PM, Geoffrey Garen [EMAIL PROTECTED] 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. 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 WorkerContext. 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? No the content of the URL must be JavaScript. In fact it must be JavaScript intended to be used in a worker to do anything useful. Since the whole point of the worker is to do JavaScript work, should 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 execution? 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. - a
