Re: Limited DOM in Web Workers

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