Bug 14086 - When performing AJAX type queries, they are already asynchronous and already occur in another thread. However, I have found that parsing the XML reply and converting that to a representation usable by the javascript application can result in freezes to t
When performing AJAX type queries, they are already asynchronous and already ...
Status: RESOLVED WONTFIX
Product: WebAppsWG
Classification: Unclassified
Component: Web Workers (editor: Ian Hickson)
unspecified
Other other
: P3 enhancement
: ---
Assigned To: contributor
public-webapps-bugzilla
http://www.whatwg.org/specs/web-apps/...
:
: 14093 14116 14137 14138 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-08 14:41 UTC by contributor
Modified: 2012-04-26 22:38 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2011-09-08 14:41:49 UTC
Specification: http://www.w3.org/TR/2011/WD-workers-20110901/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
When performing AJAX type queries, they are already asynchronous and already
occur in another thread.  However, I have found that parsing the XML reply and
converting that to a representation usable by the javascript application can
result in freezes to the GUI for large amounts of data.  When I tried to put
the processing of the AJAX reply in a web worker (I tried to put the XML
processing and marshaling to javascript amenable format in a web worker), I
found that the web worker could not use the DOM Parser and the javascript data
assembled by the web worker had to be converted to a string to be pushed back
via a message to the main thread.  So web workers do not appear to solve what
appears to be a fairly common problem - a delay processing alot of XML data
from the server.  The ability to assemble data in a handy format in one thread
and then give it to the main thread, without incurring a time penalty to
essentially recreate the data in the main thread, would be nice to have.  It
appears what we have now are multiple processes rather than threads (no data
sharing).  Why not modify the core javascript language to add threads?	(Like
C++0x or Java).  Why can't the web workers use an XML parser?

Posted from: 199.89.158.132
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Comment 1 Michael Hanson 2011-09-08 16:03:53 UTC
This issue came up on the list in January 2011; here is a pointer to the thread: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg59

A short summary of the conversation is:
* DOMParser implementations may not be (and in most cases, are definitely not) thread safe today.
* There are features of the DOMParser that cannot easily be placed into a web worker (loading of external DTDs being a major one)
* Implementors are encouraged to experiment with pure-JS parser implementations to see what works and to provide feedback.

(Not expressing a Mozilla opinion here - just summarizing list activity to keep the pointers alive)
Comment 2 Simon Pieters 2011-09-08 20:06:15 UTC
Seems to me like this use case is asking for async parsing APIs.
Comment 3 Simon Pieters 2011-09-13 12:19:18 UTC
*** Bug 14137 has been marked as a duplicate of this bug. ***
Comment 4 Simon Pieters 2011-09-13 12:19:24 UTC
*** Bug 14138 has been marked as a duplicate of this bug. ***
Comment 5 Simon Pieters 2011-09-13 12:19:29 UTC
*** Bug 14116 has been marked as a duplicate of this bug. ***
Comment 6 Simon Pieters 2011-09-13 12:19:36 UTC
*** Bug 14093 has been marked as a duplicate of this bug. ***
Comment 7 Jonas Sicking 2011-09-13 18:05:24 UTC
I don't think this is a question of async or not, but a question of DOM or not.

It's been well established that we can't expose a DOM in workers. What we could do however is a SAX-based API. We could either create a async one that somehow ties in to XHR, or we could do a sync one which takes a string and synchronously calls callbacks.
Comment 8 Travis Leithead [MSFT] 2011-09-28 01:12:08 UTC
Would you expect some new type of parser for Web Workers to be done in a separate spec? Such a feature could be useful for non-worker scenarios as well...
Comment 9 Ian 'Hixie' Hickson 2011-10-18 20:22:02 UTC
I'd highly recommend just using JSON instead of XML, personally.
Comment 10 Art Barstow 2011-11-11 19:04:33 UTC
I asked the following questions about this bug in http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0831.html 

What, if anything, should we do with this bug?

Given it is marked as an "enhancement", does anyone consider this mandatory to address before publishing a LC? If yes, what is your proposed resolution?

Would anyone object to moving to LC/CR with this bug open?
Comment 11 Travis Leithead [MSFT] 2011-11-11 20:43:20 UTC
I think this is a feature request. It appears to be a request for a Web Worker-friendly SAX-like XML parser. I don't believe this is something that we should try to add to the current spec.

I'd resolve this to "next version" (or equivalent) and pursue the idea in that forum. I certainly think it's a worthwhile idea to pursue.
Comment 12 David Levin 2011-11-11 21:19:15 UTC
(In reply to comment #11)
> I think this is a feature request. It appears to be a request for a Web
> Worker-friendly SAX-like XML parser. I don't believe this is something that we
> should try to add to the current spec.

Agreed that it makes sense to not do this in the current spec and discuss later. (I work on Web Workers in Chromium.)
Comment 13 Art Barstow 2011-11-21 13:49:34 UTC
Jonas, Simon, Michael, Hixie - would you please provide your feedback on whether this bug should block movement to Recommendation?
Comment 14 Ian 'Hixie' Hickson 2011-12-03 03:41:27 UTC
I would vote for WONTFIX. I don't think this is a feature we should ever provide.
Comment 15 Ian 'Hixie' Hickson 2012-04-26 22:38:44 UTC
Marking WONTFIX as per last comment. See comment 9.