Re: =[xhr]

Spinner is not sufficient.  All user activity must stop.  They can take  a 
coffee break if it takes too long.  Browser must be frozen and locked down 
completely.  No other options are desirable.  All tabs, menus, etc. must 
be frozen.  That is exactly the desired result.



From:   "Tab Atkins Jr." <jackalmage@gmail.com>
To:     nmork_consultant@cusa.canon.com, 
Cc:     public-webapps <public-webapps@w3.org>
Date:   08/01/2014 06:33 AM
Subject:        Re: =[xhr]




On Aug 1, 2014 8:16 AM, <nmork_consultant@cusa.canon.com> wrote:
>
> In this case, a freeze on all browser operations is desirable.  The 
thread cannot be interrupted, and if it is interrupted (by browser closure 
or other such) then the transactions are immediately stopped and no update 
will occur (this is the most desirable outcome.)  
Assuming you're handling transactions yourself, using async XHR has no 
effect on this. (The browser doesn't provide any transactions for you.)
Async XHR doesn't continue after tab closure.
> Async is not desirable, since it gives control back to the browser and 
the user has a false impression that interaction may be ok or even 
desirable.  In this case it is not, it is an all stop until complete 
requirement.  
You can throw up a spinner to indicate that if you want, and get the same 
effect. The spinner solution lets you do more things, too, such as 
providing feedback or other information to the user. (Or just allowing 
hover effects to work - freezing the main thread restricts a *lot* of 
things.)
> I use both async and sync xmlhttprequests, and they both have their 
place.  Please do not deprecate sync requests simply because you cannot 
imagine where they would be desirable.  When they are needed, they are 
ABSOLUTELY needed and async requests are not only NOT desirable, but can 
lead to potentially disastrous results. 
Sync XHR offers you literally nothing over async XHR besides a little bit 
of restrictive simplicity. There is absolutely no situation in which sync 
XHR is actually required.
~TJ