- From: Jack Coulter <jscinoz@jscinoz.org>
- Date: Sun, 09 Jan 2011 18:29:39 +1100
- To: public-webapps@w3.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 UTC