(Moving this thread over to the WebApps WG.)
On Sat, 05 Dec 2009 00:06:35 +0100, Alexey Proskuryakov <[email protected]>
wrote:
On 04.12.2009, at 14:30, Jonas Sicking wrote:
However for the events that are fired as a result of network activity,
I see no reason to fire these events asynchronously from that code.
Sounds like we're in complete agreement here. I've missed the change
from sync to async dispatch when it was made in XHR specs (both v1 and
v2), and I think that it should be reverted.
That sounds right. I initially misunderstood the way the task queue would
work together with XMLHttpRequest. It seemed sort of natural that events
for asynchronous requests would be queued as tasks, but I see that if the
network event itself is queued we can remove that.
So to be clear, under step seven of the send() method in
http://dev.w3.org/2006/webapi/XMLHttpRequest/#the-send-method
nothing would change. We still want to queue tasks for things that happen
on the network so that the "same-origin request event rules" run
asynchronously as it were. However, everything that follows from that
should no longer queue a task, right? I.e. once the initial task queued as
result of network activity is run everything should be done synchronously.
Later on in the thread on the WHATWG you and Ian allude to difficulties
with the XMLHttpRequest specification with respect to race conditions if
we rearrange this. Could you perhaps give an example as I am not sure what
would be an issue if I make the above changes.
--
Anne van Kesteren
http://annevankesteren.nl/
