Re: =[xhr]

>
> 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.


While I personally agree with you that synchronous XHRs have their rare but
distinct uses, preventing DB corruption doesn't seem like a realistic one
as the synchronicity of an XHR only affects the single client who is making
the request.  If your intranet app has more than 1 client, you would still
need to guarantee clean DB operation queuing on the backend.

Sincerely,
    James Greene



On Mon, Aug 4, 2014 at 8:29 AM, <nmork_consultant@cusa.canon.com> wrote:

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