- 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
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic26494.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 26 September 2007 05:58:15 UTC