Re: Limited DOM in Web Workers

On Sat, Jan 8, 2011 at 11:29 PM, Jack Coulter <jscinoz@jscinoz.org> wrote:
> 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?

My recommendation is that people experiment with this by writing JS
libraries to fulfill this use cases (there are already both XML and
HTML parsers written purely in javascript). That will provide feedback
to spec writers and browser implementers as to what solutions work and
what advantages/disadvantages they have.

/ Jonas

Received on Sunday, 9 January 2011 13:27:35 UTC