- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 07 Jan 2011 22:34:14 -0500
- To: Jack Coulter <jscinoz@jscinoz.org>
- CC: public-webapps <public-webapps@w3.org>
On 1/7/11 2:29 PM, Jack Coulter wrote: > I'm not talking about allowing Worker's to manipulate the main DOM tree of > the page, but rather, exposing DOMParser, and XMLHttpRequest.responseXML, > and a few other objects to workers, to allow the manipulation of DOM trees > which are never actually rendered to the page. Whether they're rendered doesn't necessarily matter if the DOM implementation is not threadsafe (which it's not, in today's UAs). That said... > This would allow developers to parse and manipulate XML in workers, freeing > the main thread of a page to perform other tasks. ... > An example of a use-case, I'd like to hack on the Strope.js XMPP > implementation to allow it to run in a worker thread, currently this is > impossible, without writing my own XML parser, which would undoubtedly > be slower than the native DOMParser) If you think you could do this with your own XML parser, is there a reason you can't do it with e4x (I never thought I'd say that, but this seems like an actually good use case for something like e4x)? That should work fine in workers in Gecko-based browsers that support it, and doesn't drag in the entire DOM implementation. That leaves the problem of convincing developers of those ECMAScript implementations that don't support e4x to support it, of course; while things like http://code.google.com/p/v8/issues/detail?id=235#c42 don't necessarily fill me with hope in that regard it may still be simpler than convincing all browsers to rewrite their DOMs to be threadsafe in the way that would be needed to support exposing an actual DOM in workers. -Boris
Received on Saturday, 8 January 2011 03:34:48 UTC