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

> -----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.



> > I believe this has been adequately discussed in my earlier replies.
>
> I'm sorry, I quite possibly have missed it, I apologize for that, I'm
> trying to juggle a number of issues in this WG as you can see :). So
> feel free to send me a pointer to an archived mail (archive is
> available
> at http://lists.w3.org/Archives/Public/public-webapps/) or reiterate
> the
> reasons here.
>
> / Jonas

Received on Friday, 20 June 2008 21:11:22 UTC