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: Thursday, June 19, 2008 7:22 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: Thursday, June 19, 2008 2:38 PM
> >> To: Sunava Dutta
> >> Cc: Ian Hickson; Zhenbin Xu; 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
> >>
> >> Sunava Dutta wrote:
> >>> Thanks Ian, Zhenbin for clarifying the issues and a continuing very
> >>> productive discussion.
> >>> Meanwhile, I'm summarizing some of our requests for the editor
> based
> >>> on issues we've had an opportunity to clarify...There are many
> >>> conversations going on and I'd hate to see points getting lost and
> >>> would like the specs/test cases updated for issues where
> discussions
> >>> are not ongoing.
> >>>
> >>>
> >>> -Ongoing discussion: Specify the parseError attributes for Document
> >>> Objects or specify this can be sent out of band. This could be
> >>> something we don't have to hold the XHR spec back for as long as we
> >>> make a note in the specification that this is pending. There are
> >>> people currently talking for and/or against it. Zhenbin is
> >>> articulating IE's point.
> >> Sounds good to me. We have an informative "Not in this
> specification"
> >> section already, sounds like a good idea to add there.
> >>
> >>> - Throwing exceptions on state violations is easier to understand
> and
> >>> we should change the spec to reflect this. (for the sake of a
> >>> consistent programming model). The spec should have
> INVALID_STATE_ERR
> >>> exception (the exact language can be worked out)  if a site is
> >>> expecting an exception and gets a null as this would not work if
> the
> >>> developer is trying to write a wrapper object in XHR. I haven't
> heard
> >>> any strong objection here or compelling argument against it that's
> >>> been sustained.
> >> I do think there has been some disagreement here. Anne has commented
> on
> >> reasons for returning null rather than throwing an exception, and I
> >> think I agree with him. I think the correct cause of action here is
> to
> >> raise an issue in the issue tracker.
> >>
> >
> > [Zhenbin Xu] I am not familiar with the process here.  How does issue
> > gets resolved when it is in issue tracker?
>
> Having it in the issue tracker just makes it easier to track since the
> issue tracker keeps track of all emails on the subject (if you put
> ISSUE
> XX in the subject).
>
> > We have enough debate already
> > that there is technical merit to throw exception rather than null. It
> is
> > not going to be productive for us to keep spending time on it.
>
> I do agree we have debate, I don't agree we have agreement on that
> throwing an exception is the right thing to do.
>
> The argument for returning null is that it makes for a cleaner API,
> exceptions should only be thrown in exceptional circumstances. And
> based
> on available data it doesn't seem like sites currently care one way or
> another, so I think we should go for the cleaner API.
>
> What is the argument for throwing an exception?
>
> / Jonas


[Zhenbin Xu] State violations.  XHR is designed as a state machine. The whole
spec is written centered around states (OPENED, SENT etc.).  Remember we
are not designing a new object.  It is an object invented long time ago
and the inventor had decided to pick the exception model.

Yes there are complexities surrounding a state machine approach. This
is why in our new XDR model, we no longer use the readyState mode.
However we cannot retrofit an object that was created almost ten years ago.

Received on Friday, 20 June 2008 02:36:24 UTC