Re: =[xhr]

You are acting as though I have to choose one or the other and stick with 
it.  Async has it's uses, especially for GET operations.  However, many 
(not all) POST operations require only 1 channel to be active at a time, 
especially in intranet applications.  No user wants to be given the 
freedom to accidentally screw up.

The problem with recent developments in the web browser world, it seems 
that things that are useful are deprecated then disappear, even if useful 
for one purpose or another and that is my request.  There seems to be some 
confusion and everyone is acting as if I only wish to use synchronous 
xmlhttprequests.  If async were to be deprecated, I would complain as much 
as I am or more. 

HOWEVER, I am getting the distinct impression that even though I find 
synchronous xmlhttprequests extremely useful in some situations to prevend 
DB corruption--usually I avoid these situations, due to the negative 
impacts you have all described so well in your emails.  That said, there 
are times when it is the only option.  Everyone in your group seems to 
have taken the attitude that I am mistaken, confused, or stupid.  I am 
only requesting for synchronous xmlhttprequests NOT to be deprecated and 
NOT to be eliminated from the specification.  It's pretty clear to me now 
that my request will not be considered.  Thank you all for your responses.



From:   Austin William Wright <aaa@bzfx.net>
To:     Glenn Maynard <glenn@zewt.org>, 
Cc:     nmork_consultant@cusa.canon.com, "Tab Atkins Jr." 
<jackalmage@gmail.com>, public-webapps <public-webapps@w3.org>
Date:   08/02/2014 02:11 AM
Subject:        Re: =[xhr]




On Fri, Aug 1, 2014 at 2:01 PM, Glenn Maynard <glenn@zewt.org> wrote:
On Fri, Aug 1, 2014 at 8:39 AM, <nmork_consultant@cusa.canon.com> wrote:
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. 

My browser isn't yours to lock down.  My menus aren't yours to freeze. 
 You don't get to halt my browser, it doesn't belong to you.

In this case, a freeze on all browser operations is desirable.

It may be desirable to you, but it's never desirable to the user, and 
users come first.


This seems rather cold (I wouldn't presume that the described usage is 
actually bad for the users, not having seen the program in question), 
though assertion is technically correct (if users are at odds with 
development of a technical report, users come first). I would point out:

It may be cheap for the developer to use synchronous mode, but it's not 
the UI event loop works, and as such it's almost always a bad proposition 
for the user. It's not a sustainable coding pattern (what if you want to 
listen for two operations at the same time?), it's generally a hack all 
around. It doesn't negate the need for your application to perform sanity 
checks like "Is the data loaded? Does performing this operation make 
sense?", even if using synchronous mode *seems* to let you avoid such 
checks.

Maybe there's another reason: Good idea or no, removing this feature DOES 
break reverse compatibility with the de-facto behavior of many Web 
browsers. I'm not sure that's reason enough to standardize on the 
behavior, though. However, it may be enough a reason to file a bug report 
if the behavior ever breaks (though if they come back and say "it was 
never standardized behavior to begin with, you shouldn't have been using 
it in production", I can't really blame that either).

Austin Wright.