Re: Limited DOM in Web Workers

On Fri, Jan 7, 2011 at 7:34 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

I would strongly advice using e4x. It seems unlikely to be picked up
by other browsers, and I'm still hoping that we'll remove support from
gecko before long.

My question is instead, what part of the DOM is it that you want? One
of the most important features of the DOM is modifying what is being
displayed to the user. Obviously that isn't the features requested
here. Another important feature is simply holding a tree structure.
However plain javascript objects do that very well (better than the
DOM in many ways).

Other features of the DOM include form handling, parsing attribute
values in the form of integers, floats, comma-separated lists, etc,
URL resolving and more. Much of this doesn't seem very interesting to
do on workers, or at least important to have the browser provide an
implementation for in workers.

Hence I'm asking, why specifically would you like to access a DOM from workers?

/ Jonas

/ Jonas

Received on Saturday, 8 January 2011 09:10:51 UTC