[xhr] events for async requests (was: Re: [whatwg] Thread to run Web Socket feedback from the protocol ?)

(Moving this thread over to the WebApps WG.)

On Sat, 05 Dec 2009 00:06:35 +0100, Alexey Proskuryakov <ap@webkit.org>  
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/

Received on Wednesday, 16 December 2009 14:25:57 UTC