W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: XMLHttpRequest Comments from W3C Forms WG

From: Marcos Caceres <marcosc@opera.com>
Date: Sun, 20 Dec 2009 21:42:35 +0100
Message-ID: <b21a10670912201242nce56578n6f4576cb881eb3c4@mail.gmail.com>
To: Alex Russell <alex@dojotoolkit.org>
Cc: Maciej Stachowiak <mjs@apple.com>, "Klotz, Leigh" <Leigh.Klotz@xerox.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, WebApps WG <public-webapps@w3.org>, Forms WG <public-forms@w3.org>
On Sat, Dec 19, 2009 at 4:01 AM, Alex Russell <alex@dojotoolkit.org> wrote:
>
> On Dec 18, 2009, at 3:09 PM, Marcos Caceres wrote:
>
>> On Fri, Dec 18, 2009 at 4:40 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>
>>> On Dec 17, 2009, at 3:15 PM, Klotz, Leigh wrote:
>>>
>>>> OK, so is the conclusion that XHR is implementable only in HTML5 and
>>>> should be re-titled "XMLHttpRequest in HTML5" or something similar?
>>>
>>> I think your premise is false, and I don't such a retitling would be
>>> helpful. The XHR spec does not require a full implementation of HTML5. It
>>> only references some concepts from HTML5. The XHR spec could be
>>> implemented
>>> in an SVG or HTML4 or XHTML 1.0 implementation that did not support most
>>> aspects of HTML5 at all, as long as it could satisfy the requirements
>>> implied by those definitions. Your proposed title change would imply that
>>> the XHR spec could only be implemented by an HTML5 UA, but that is not
>>> accurate.
>>>
>>
>> So, basically, what you are saying is that you can't pick up this spec
>> and, say, implement it in [insert favorite programming language]
>> easily without a whole bunch of baggage from HTML5? Seems like pretty
>> poor engineering, but that might not be the fault of the specification
>> (i.e., given that XHR is a reverse engineering of something that is
>> closely tied to browsers). Its a shame though that we can't liberate
>> these things from browser behavior so they are more generally
>> applicable. I've seen XHR implemented in other classes of product, but
>> it'd be a shame if such products can't ever conform to the spec.
>
> That's sort of a perverse way to look at it. It's not like XHR is a *good*
> API. It's a passible Win32 COM interface, but you'd want a lot more control
> over many aspects of the HTTP discussion if you were doing this in an
> environment that's not a browser. What other environment has a same-origin
> policy? Unless the other language you're talking about is C++, I don't think
> anyone should be toting XHR around with them like it's some sort of a
> liberated gem. It's a bad JS API and would be as bad (or worse) in many
> other dynamic languages.

Yeah, you are right. I guess we get so used to having these crappy
retrospective APIs around that one forgets that things could be done
in better ways - thankfully decent frameworks have been built around
them to make these things usable.

-- 
Marcos Caceres
http://datadriven.com.au
Received on Sunday, 20 December 2009 20:43:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT