On 8 Apr 2009, at 02:29, Jonas Sicking wrote:
But it's for a limited time. In a few years hopefully all browsers
supports cross site XHR. And if you can already today follow the
advice that you should not rely on XHR not honoring your request just
because it's a cross site URI.
You are proposing a model where there's two types of XHR objects. One
where we specifically tell users that you can rely on the request
won't be sent cross site, and one where you can't.
Put differently: Current web applications have a contract with the
underlying browser that prevents cross-site requests from happening
when XMLHttpRequest is used.
That's a contract that software authors might very well rely on.
The proposal within the working group (which is implemented by a
number of browser vendors) is to abolish this guarantee.
The approach that's implemented by IE8 (with a separate
XDomainRequest) matches Tyler's requirement, and preserves the
existing contract for XHR.
While I can see how a single API would be a useful thing to have, I
can also follow Tyler's argument; the trade-off here is indeed between
following the principle of least surprise for existing Web
Applications and a certain sense of simplicity for future applications.
Incidentally, just framing this as "XHR vs XDR" is a bit simplistic:
E.g., one could imagine a method "enableCrossSiteRequests" (or
something like that) which needs to be invoked before XHR can do cross
site requests.
