[whatwg] Web Sockets

[Brady Eidson]

 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: whatwg-bounces at lists.whatwg.org
>> [mailto:whatwg-bounces at lists.whatwg.org] 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
>>
>>
>