- From: Jon Ferraiolo <jferrai@us.ibm.com>
- Date: Wed, 26 Sep 2007 08:10:00 -0700
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: "public-webapi@w3.org" <public-webapi@w3.org>, Sunava Dutta <sunavad@windows.microsoft.com>
- Message-ID: <OF68B9ED49.9602B9B3-ON88257362.0051FC58-88257362.00535068@us.ibm.com>
I haven't been following the technical discussion in enough detail to have a definitive opinion about whether there is a need to address Microsoft's concerns about ensuring backwards compatibility with existing web content, but I have a knee jerk positive reaction whenever I hear a browser vendor express concerns about "not breaking the Web", meaning that they want to make sure that future versions of browsers do not cause existing content to quit working. I don't know if a new class (XHR2) or a version property are truly required in order to address backwards compatibility with existing content (i.e., don't break the Web). I'll leave that to the experts on the WG. But I will point out that nearly all Web developers today that use XHR use a wrapper JavaScript function. Here is a simple one that reflects what you'll find in an Ajax tutorial: function getHTTPObject() { var xmlhttp; /*@cc_on @if (@_jscript_version >= 5) try { xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); } catch (E) { xmlhttp = false; } } @else xmlhttp = false; @end @*/ if (!xmlhttp && typeof XMLHttpRequest != 'undefined') { try { xmlhttp = new XMLHttpRequest(); } catch (e) { xmlhttp = false; } } if (!xmlhttp && window.createRequest) { try { xmlhttp = window.createRequest(); } catch (e) { xmlhttp=false; } } return xmlhttp; } I looked at the Dojo and Yahoo libraries. Their XHR wrapper logic is similar but is implemented using a table-driven approach. Dojo includes the following array "d._XMLHTTP_PROGIDS = ['Msxml2.XMLHTTP', 'Microsoft.XMLHTTP', 'Msxml2.XMLHTTP.4.0'];" and then loops through it before returning an XHR object to the application. Therefore, if the WG concludes that MS's backwards compatibility concerns are valid, and therefore it becomes necessary to create either a new class or attach version data to the XHR class, then do so in a manner that allows JS wrapper functions to include appropriate conditional logic. Jon Lachlan Hunt <lachlan.hunt@lac hy.id.au> To Sent by: Jon Ferraiolo/Menlo Park/IBM@IBMUS public-webapi-req cc uest@w3.org Sunava Dutta <sunavad@windows.microsoft.com>, "public-webapi@w3.org" 09/26/2007 05:48 <public-webapi@w3.org> AM Subject Re: FW: Feedback from the IE Team: Web API XHR Draft Jon Ferraiolo wrote: > The idea that there is a new JavaScript class (XHR2?) or a different > version of the XHR object seems reasonable to me. Introducing a brand new version of XHR doesn't solve the existing interoperability problems the current version that people actually use. I am opposed to introducing another new object for this problem. IE already has ActiveXObject("Microsoft.XMLHTTP") that it can use for legacy compat while making XMLHttpRequest() conform to this spec. -- Lachlan Hunt http://lachy.id.au/
Attachments
- image/gif attachment: graycol.gif
- image/gif attachment: pic17827.gif
- image/gif attachment: ecblank.gif
Received on Wednesday, 26 September 2007 15:11:23 UTC