W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Limited DOM in Web Workers

From: Jack Coulter <jscinoz@jscinoz.org>
Date: Sat, 08 Jan 2011 20:07:37 +1100
To: public-webapps@w3.org
Message-Id: <1294477089-sup-6841@jscinoz.org>
Excerpts from Boris Zbarsky's message of Sat Jan 08 14:34:14 +1100 2011:
> 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...
> 

Sorry, I wasn't really clear. What I meant was, a private DOM hierarchy. You
still wouldn't be able to access it in multiple places simultaneously, and
you'd still have to serialise it to a string to use it in postMessage. Forgive
my ignorance, but if this were the case, then isn't the thread-safety issue
effectively sidestepped? 

> > This would allow developers to parse and manipulate XML in workers, freeing
> > the main thread of a page to perform other tasks.
> ...
> 

Why '...'? Did I say something in error here?

> > 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.

I know of E4X, and while I think it's a really nice language feature, the lack
non-gecko support makes it substantially less useful.

> 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.

Heh, some coincidence, I was actually reading through this very thread earlier,
today. After thinking about it, I'd say that E4X would be the best solution for
XML in Workers, but would need to be supported more widely.
Received on Saturday, 8 January 2011 09:15:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT