From the link you provide:
"In some situations, it is more natural to make a blocking call and
have the call return the received value, but this synchronous-style
XHR is currently plagued with the risk of locking up the user's
browser window forever as there is no timeout used in waiting for data
from the server."
The flaw in this argument is that they only see locking up the browser
window "forever" as an evil. This is wrong. It is not okay to lock
up the browser window. Ever.
They go on to explain how if only there were a way to lock up the
browser window *for a little while*, that would be okay:
"1. Add a timeout property to the XMLHttpRequest object that controls
how long an XHR call will wait for the server before aborting the call
and returning null or exception"
This is not a solution. Look at native applications for example. 20
years ago it might have been common - not acceptable, but common - to
block the main thread waiting for a long running i/o operation with
the safety net of a timeout. This is simply not done anymore. Native
applications have turned to either asynchronous i/o, or running
synchronous i/o on a background thread.
"2. Improve handling of UI events during a sync XHR so UI gets
repainted when needed and animated GIFs are run." ... "allows the user
to abort the blocking operation"
This is not user-centric programming and seems pretty unacceptable to
me. The user already said they want to close the browser window, and
they should not have to repeat themselves.
As a coder, I sympathize with those developers who would love the
convenience of programming with synchronous i/o.
As a browser developer and a user of the real web, I know it's a
downright dangerous path to rationalize repeating these past mistakes.
Per my original response, the main objection my coworkers and I have
is with synchronous i/o on the main thread. Now that Hixie has given
us a glimpse at what will become a fleshed out worker thread spec, I
think it's entirely reasonable to allow such operations on such a
background thread.
As long as protections are in place to make sure "convenience-minded"
developers can't lock up the main thread waiting for a background
operation to complete, of course... ;)
~Brady
On Jul 11, 2008, at 12:04 PM, Mike Wilson wrote:
Blocking I/O on the main thread is ok if it's possible to specify
a timeout for the I/O operation, see:
http://www.openajax.org/runtime/wiki/Synchronous_XHR_Enhancements
and if the UA'a user interface is kept responsive (running animated
GIFs, repainting UI etc) and allows the user to abort the blocking
operation (f ex as a new use of the Stop button), see:
http://www.openajax.org/runtime/wiki/Browser_Unresponsive_Mode_Enhancements
Best regards
Mike Wilson
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson
Sent: den 7 juli 2008 22:50
To: Mike Ter Louw
Cc: whatwg; Ian Hickson
Subject: Re: [whatwg] Web Sockets
On Jul 7, 2008, at 12:57 PM, Mike Ter Louw wrote:
Joking aside, should a blocking read/recv call be made available?
In some cases additional lag may be an acceptable compromise for
maintaining the JavaScript call stack until a response arrives.
My personal take (and the take of most of the people I work with) is
that blocking i/o on the main thread should be out of the question.
No matter what assumptions, guarantees, or compromises are
understood
in a rationalization for allowing it, we've seen time and time again
that they backfire and lead to poor user experiences and bad
performance problems.
Notice I'm explicitly mentioning the main thread - if we get
a clear,
clean spec for worker threads and we restrict blocking i/o to such
worker threads, then sure - go for it!
~Brady
