W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: <New: Tracking Issues in XHR that we raised>RE: <Was: Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 20 Jun 2008 14:31:53 -0700
Message-ID: <485C21C9.6090107@sicking.cc>
To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
CC: Sunava Dutta <sunavad@windows.microsoft.com>, Ian Hickson <ian@hixie.ch>, "public-webapps@w3.org" <public-webapps@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>

Zhenbin Xu wrote:
> 
> 
>> -----Original Message-----
>> From: Jonas Sicking [mailto:jonas@sicking.cc]
>> Sent: Friday, June 20, 2008 2:05 PM
>> To: Zhenbin Xu
>> Cc: Sunava Dutta; Ian Hickson; public-webapps@w3.org; IE8 Core AJAX
>> SWAT Team
>> Subject: Re: <New: Tracking Issues in XHR that we raised>RE: <Was:
>> Further LC Followup from IE> RE: Potential bugs identified in XHR LC
>> Test Suite
>>
>> Zhenbin Xu wrote:
>>>
>>>> -----Original Message-----
>>>> From: Jonas Sicking [mailto:jonas@sicking.cc]
>>>> Sent: Friday, June 20, 2008 1:19 PM
>>>> To: Zhenbin Xu
>>>> Cc: Sunava Dutta; Ian Hickson; public-webapps@w3.org; IE8 Core AJAX
>>>> SWAT Team
>>>> Subject: Re: <New: Tracking Issues in XHR that we raised>RE: <Was:
>>>> Further LC Followup from IE> RE: Potential bugs identified in XHR LC
>>>> Test Suite
>>>>
>>>> Zhenbin Xu wrote:
>>>>> Jonas, I don't feel you have summarized our position properly.  We
>>>>> said it should be exception but we are willing to accommodate other
>>>>> implementations for the spec to have a leeway there and avoiding
>>>>> protracted discussions.
>>>> I assume you mean by the "null or exception" proposal? I think many
>>>> people have made it quite clear that they think that is the least
>> good
>>>> solution as it doesn't produce interoperability across browsers.
>>>>
>>>>> We have absolutely no problem for the spec to
>>>>> clearly state that exception is the best API that should be
>> followed.
>>>> Hehe, yes, that has been quite clear :)
>>>>
>>>>> It is backed by technical arguments on my replies.  Let's expand
>> more
>>>>> there if you feel those are inadequate.
>>>> Yes please do, I'm curious as to what those technical arguments are.
>>>> The
>>>> one I've heard so far is concern about site compatibility with
>>>> returning
>>>> null. I.e. you guys are concerned that sites will break if an
>> exception
>>>> isn't thrown.
>>>>
>>> [Zhenbin Xu]  We are concerned because returning null is not a
>> consistent,
>>> predictable programming model. It is a deviation from other part of
>> the XHR
>>> design, as well as the state machine approach that entire spec is
>> based on.
>>
>> Which other parts of the spec is it inconsistent with. I definitely
>> agree that consistency is important. Looking at the spec it seems like
>> returning null is consistent with .responseText, but not consistent
>> with
>> .status and .getResponseHeader().
>>
>> Ideally we should have consistency across all these properties.
>>
> 
> [Zhenbin Xu]  .statusText, .getAllResponseHeaders(), send() all raise
> INVALID_STATE_ERR as well.

So if we can change .responseText to also throw an exception then I'd be 
fine with having .responseXML also throw.

/ Jonas
Received on Friday, 20 June 2008 21:32:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:26 GMT