RE: XHR LC comments

Inline...

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@opera.com]
> Sent: Saturday, May 17, 2008 5:45 AM
> To: Julian Reschke
> Cc: Maciej Stachowiak; Sunava Dutta; Web API WG (public)
> Subject: Re: XHR LC comments
>
> On Sat, 17 May 2008 14:23:24 +0200, Julian Reschke <julian.reschke@gmx.de>
> wrote:
> > Anne van Kesteren wrote:
> >> On Sat, 17 May 2008 11:56:45 +0200, Julian Reschke
> >> <julian.reschke@gmx.de> wrote:
> >>> But what IMHO happens all over again is that strange choices in the
> >>> design are defended with the statement "this is what the vendors do,
> >>> or want to do", and when we check it, that turns out to be incorrect.
> >>  Could you point out one such example? I've actually tested a fair
> >> amount
> >
> > They are in the current threads.
> >
> > - "add" semantics for setRequestHeader
> > - semantics for setRequestHeader(...,null)
> > - silent data loss for send() when DOM can't be serialized
> > - ...
>
> I think only for the last one I have suggested that I rather not change it
> based on that this seems like a safer choice. I have not seen any tests
> that show that implementations actually throw in that case.
>
>
> >> of stuff, including headers, methods, etc. I agree that some of the
> >> details of headers need to be worked out. For null/""/undefined I've
> >> been waiting for the Web IDL specification. For which headers can be
> >> set by the user agent I don't really have an answer and that part has
> >> not been defined as such. That setRequestHeader() always appends was a
> >> conscious choice to be in line with Internet Explorer. Initially the
> >> design was so that it special cased a bunch of headers that did not
> >> allow duplication which would have been more in line with Firefox, but
> >> given that it is not a fixed list and the Internet Explorer route
> >> seemed more appropriate.
> >
> > Well, not to me. And apparently not to FF, as FF3 seems to ship with be
> > non-compliant behavior.
>
> To my best knowledge Mozilla hasn't started implementing the specification
> yet. I've seen several comments in their public bug database to the effect
> that they rather wait until it reaches CR.
>
>
> > setRequestHeader() currently simply is broken. We should deprecate it,
> > and add new methods with well-defined semantics:
> >
> > - removeHeader(...) (or specify set with null to mean remove)
> > - addHeader...
> > - getHeader...
>
> "Deprecating" a method does not help implementations converge. Besides,
> for typical usage there's no issue in using this header at all.
>
[Sunava Dutta] I agree with Anne here. Deprecating an existing implementations and re-engineering XHR is something we just cannot accept. This spec should be designed to reflect reality and seek interoperability for each and every single section/method/event with at least one (I think the W3C mandates two?) existing implementations. That does not mean the entire spec is aligned with FF or IE, but it should be harmonious at any instance with one existing implementation.
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

Received on Monday, 19 May 2008 19:14:06 UTC