W3C home > Mailing lists > Public > public-webapi@w3.org > September 2007

Re: FW: Feedback from the IE Team: Web API XHR Draft

From: Jon Ferraiolo <jferrai@us.ibm.com>
Date: Tue, 25 Sep 2007 22:57:02 -0700
To: Sunava Dutta <sunavad@windows.microsoft.com>
Cc: "public-webapi@w3.org" <public-webapi@w3.org>
Message-ID: <OFA9FFFEAD.76E3F1B5-ON88257362.001FEE9F-88257362.0020B022@us.ibm.com>
The idea that there is a new JavaScript class (XHR2?) or a different
version of the XHR object seems reasonable to me. Most developers today
either use an Ajax library or develop their own wrapper function to address
browser incompatibilities, so it seems reasonable to have a new JavaScript
class that corresponds to the new W3C spec because the wrapper functions
can be upgraded to see if the new XHR is supported and fallback to existing
logic if it is not supported. Therefore, make sure that it is quick and
easy for JavaScript to figure out if the new API is available within the
current browser.

This concept of taking into account Ajax libraries that are able to bridge
between the dirty more fragmented past and a cleaner more standardized
future probably applies to many other issues within the WebAPIs and WAF
groups.

Jon
IBM & OpenAjax Alliance



                                                                           
             Sunava Dutta                                                  
             <sunavad@windows.                                             
             microsoft.com>                                             To 
             Sent by:                  "public-webapi@w3.org"              
             public-webapi-req         <public-webapi@w3.org>              
             uest@w3.org                                                cc 
                                                                           
                                                                   Subject 
             09/25/2007 07:35          FW: Feedback from the IE Team: Web  
             PM                        API XHR Draft                       
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Re-summarizing the points of our feedback regarding the XHR draft for the
public list.
      ·        Interoperability/Compatibility for v1 spec for XHR is
      critical if the spec is to achieve consensus.  XHR was first
      implemented a decade ago, and a huge amount of existing content
      relies upon the stability of the existing implementation.  The v1 XHR
      spec should seek to ensure interoperability between the existing
      client implementations and the deployed base of content.
      ·        All new functionality/features should be specified in a new
      Level of the XHR specification. This will permit developers the
      freedom that comes with a new object without the risk of
      incompatibility with the hundreds of millions of existing browsers
      that implement XHR today. As you know, the purpose of versioning is
      to guarantee this compatibility while ensuring that innovation can
      proceed without risk.  This reminds me of the DOM L1 vs DOM L0, where
      the DOM L1 spec was engineering to include all new functionality over
      the DOM L0 which was assumed to be baseline interoperable across
      browsers.
      ·        The thread below has more details and specific instances.
Thanks!


From: Sunava Dutta
Sent: Tuesday, August 28, 2007 4:20 PM
To: Anne van Kesteren
Cc: Chris Wilson; Cyra Richardson; Doug Stamper; Zhenbin Xu; Levent Besik;
Eric Lawrence; Marc Silbey
Subject: Feedback from the IE Team: Web API XHR Draft

Hello Anne,
I’ve taken a pass at the spec and have a few comments below…

      ·        As you can imagine, we have a huge commitments to developers
      who build on IE and maintain legacy sites on IE. Compatibility
      consequently is not optional for us. We can’t break existing compat.
      The object in its current form has been out there for years, is very
      widely deployed and browsers like FF model our implementation.
            o   The challenge arising from the existing draft comes in the
            level of detail defined in the spec. For example, a number of
            algorithms specified in the spec (such as that for the open
            call) do not allow for accommodating different UA’s. For a new
            specification this would be great. For a spec that is based on
            existing technology that’s widely implemented around IE’s
            behavior this is a challenge since IE does not adhere to the
            algorithm.
            o   The spec specifies the table of the errors that should be
            returned and the exact text and type of the errors. The types
            and text of errors inherit from other W3C specs that we don’t
            support. We return our own errors here that do not match
            syntactically the errors the W3C defines although they are
            thrown for the same events. Specifying the exact text of the
            error is not recommended.
            o   If we were to make changes (not possible)  we would still
            leave web developers maintaining the majority of sites out
            there with the legacy XHR that’s compatible with IE while
            trying to support the new one creating manageability problems.
            o    Our testing load to simply verify compliance to the W3C
            draft is too great given the level of detail, the stability of
            our implementation and the fact that the draft is a moving
            target.
            o   The ask here is the level of granularity/ and specificity
            be reduced. It’s currently too authoritative in depth. We had
            signed off on your draft last year. This was mostly compatible
            with IE and FF while being helpful for web developers. A simple
            description of the open call and the types of parameters
            allowed, including which ones are optional would be great.
      ·        The current draft introduces new entities to the object.
      We’re ok with creating a new object (or versioned XHR object) in
      order to ensure that the standards can advance. However, a vast
      majority of developers will not be able to reliably use this as the
      millions of pages build around current IE XHR will not support them.
      This consequently will be a adoption blocker for the standard.
            o   Ensure all new entities like constants, flags etc are
            versioned or in a new object.
      ·        The draft frequently cross references specifications in the
      W3C.For example, the spec makes references to the DOM 3 events and
      core, namespaces in XML, Window Object 1.0 etc (Some of which are
      drafts themselves). We fail to see the value in implicitly embedding
      other large specs. Simplicity and standing on its own would be good.


http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8#text-response-entity-body



--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329




graycol.gif
(image/gif attachment: graycol.gif)

pic26494.gif
(image/gif attachment: pic26494.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

Received on Wednesday, 26 September 2007 05:58:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 December 2014 20:05:34 UTC