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

[Zhenbin Xu] Sounds good.  Thanks!




> / Jonas

Received on Friday, 20 June 2008 21:48:32 UTC