Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On 10/27/10 6:14 PM, Geoffrey Garen wrote:
> But, now clarified, your objection is about a much more minor case than originally specified: In the case of an intervening layer that not only wraps an XHR but also reads its data behind the scenes

Which is all of them that I've seen.  I haven't done an exhaustive 
survey, obviously, which is why I'd like to see more data.

> where the intervening layer wants the data in a format that the client does not want it in

Which is all of them, as things stand, if the client doesn't want 
responseText, right?

> and where the client has liberally sprinkled "catch any exceptions and ignore them" code around all of the intervening layer's accesses to the XHR, and/or all its own accesses to the XHR

Which is pretty common in complex web projects, in my experience... 
Then again, I see the ones people report browser bugs on, so maybe the 
other ones solve their problem themselves....

> and the client does not know to use a debugger's "pause on exceptions" feature

Or just can't reproduce on their end due to timing differences, but it 
bites users on their site with exceptions and broken functionality.

>> jquery, offhand, layers API on top of XHR.
>
> Right, but that's not the same as reading the XHR's data as it arrives.

It reads it before handing the XHR back to the consumer.  I suggest you 
read http://code.jquery.com/jquery-1.4.3.js since it's easily available.

>> Why are you making the "from their own domains" assumption?
>
> Because that's by far the most common use of XHR.

Because nothing else was supported until very recently, and because 
nothing else is supported in shipping IE as of today, no?

That's like arguing that there's now no usage of the raw bytes of the 
response on web pages, so we don't need to provide these raw bytes/

Going forward, as CORS support and cross-site XHR is actually 
implemented in UAs, I fully expect it to become much more common.  It 
probably won't be as common as same-site XHR, but I don't expect it to 
be particularly rare.

> The only difference between the first view approach and requiring explicit assignment to .responseText is which syntactic construct you would search for when something went wrong -- access or assignment.

The main difference is that with assignment at least you know you did 
something that affects what you get back, so you know you need to search 
for it to start with.  It's also clearly an explicit choice, if the 
setter is named properly.  I think any web developer who discovers that 
access changes what other access can happen would consider that a bug 
and start cursing whoever came up with the idea when he discovers it's 
by-design...  I now I would.  ;)

> But both approaches would reliably throw exceptions if a client got things wrong.

See, there's the thing.  Neither approach is all that reliable (even to 
the point of throwing sometimes but not others for identical code), and 
access is more prone to issues where which code the exception is thrown 
in is not consistent (including being timing-dependent), if multiple 
listeners are involved.

Do people really think that "action at a distance" situations where 
pulling slightly and innocuously on one bit of a system perturbs other 
parts of the system in fatal ways are acceptable for the web platform? 
They're the sort of things that one avoids as much as possible in other 
systems, but this thread is all about proposing such behaviors for the 
web platform...

-Boris

Received on Thursday, 28 October 2010 00:36:58 UTC