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: Sun, 09 Jan 2011 18:29:39 +1100
To: public-webapps@w3.org
Message-Id: <1294558141-sup-1021@jscinoz.org>
Excerpts from Boris Zbarsky's message of Sun Jan 09 10:42:46 +1100 2011:
> On 1/8/11 4:07 AM, Jack Coulter wrote:
> You're assuming that none of the DOM implementation code uses any sort
> of non-DOM objects, ever, or that if it does those objects are fully
> threadsafe.  That's just not not the case, at least in Gecko.
>
> The issue in this case is not the same DOM object being touched on
> multiple threads.  The issue is two DOM objects on different threads
> both touching some global third object.
>
> For example, the XML parser has to do some things that in Gecko can only
> be done on the main thread (DTD loading, offhand; there are a few others
> that I've seen before but don't recall offhand).
>

Ah, I didn't understand this before, thanks for the clarification.

> > 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.
>
> Well... so we're comparing a feature that's supported in Gecko but not
> other UAs to a feature that's not supported in any UA, right?  ;)
>
> (Fwiw, I think the way E4X was actually done is insane; heck it
> redefines what the |x.y()| syntax means! But perhaps some other API
> along those lines that doesn't actually create DOM nodes with all their
> weird behaviors (e.g. if you create an <img> it tries to load things off
> the network) and instead just parses XML into objects exposed to JS
> would be a better fit for workers.)

I agree this would probably be the best approach. We need to find or create
some API for *purely* manipulating/parsing/serialising XML documents, no
loading of resources like with the DOM. This is preferable to a javascript
based parser, for both developer ease (a single native implementation, rather
than a whole bunch of different javascript libraries), and speed reasons.


The real question is: Do we want to create something new? Perhaps at least
superficially resembling the DOM api, for developer familiarity. Or do we
simply want to have E4X universally supported, both in workers, and in
the main thread?
Received on Sunday, 9 January 2011 07:30:16 GMT

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