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

Adding the editor to take the next steps. Thanks,

> -----Original Message-----
> From: Zhenbin Xu
> Sent: Friday, June 20, 2008 2:47 PM
> To: Jonas Sicking
> 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
>
>
> > -----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:50:42 UTC