On 10/27/10 2:56 PM, Geoffrey Garen wrote:
Quietly providing multiple copies of data creates a subtle memory use problem.
Yes, agreed.
Explicitly throwing an exception at the site that tries to access the data in
the wrong way obviously and immediately points a finger at the problem.
Sort of. Except the failure happens at runtime in uncontrolled
circumstances and people tend to sprinkle try-and-ignore-exceptions
stuff in their web code.
The potential downside to an exception is not subtlety -- it's limited
functionality: clients are no longer allowed to ask XHR to be more than one
kind of data at once.
That's one problem. The other problem is that it's easy for one client
to break another without realizing it (possibly without both realizing
it, depending on how testing is performed). That's the "subtlety" issue...
The question is, can library authors make their code compatible with this
limitation?
The issue isn't just libraries, but the interaction of libraries and
library consumers and library consumers with each other...
But yes, this is the main question.
I don't think it's possible to answer that question until someone fleshes out
your assumption that libraries routinely intercept XHRs in transit and read
their data. Which libraries do this, when, and why?
jquery, offhand, layers API on top of XHR. Again, at this point I'd
welcome comments from library authors. I think we're sort of at an
impasse pending that in that clearly I'm not able to convince you and I
don't think repeating the same thing over and over will convince me either.
This make it impossible to decide whether to look at the text or the bytes
based on the content-type of the response (unless you allow setting the
attribute in some early-enough onStateChange callback _and_ libraries expose
XHRs in that early a state to consumers); having that ability seems like a
desirable feature.
I'm not convinced that clients loading resources from their own domains somehow
won't know the types of those resources.
Why are you making the "from their own domains" assumption?
But, if we believe this is a real concern, it seems fine to me to allow
responseType to be set some time after open, or even set implicitly by the
first access to a certain view of the response.
If we do go with the modal behavior, I would be _very_ opposed to the
"first view" approach. That just makes the problems that worry me that
much worse, since now it's _really_ easy for one consumer to screw over
another without really realizing it's doing so, and debugging such a
failure is very difficult. At least with the explicit flagging one can
look for where such flagging took place....
-Boris