- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 6 Apr 2006 18:54:58 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Cameron McCormack <cam@mcc.id.au>, Web APIs WG <public-webapi@w3.org>
On Apr 6, 2006, at 6:46 PM, Ian Hickson wrote:
>
> On Fri, 7 Apr 2006, Cameron McCormack wrote:
>>
>> Web APIs Issue Tracker:
>>>> [re creating an XHR object in non-ES languages]
>> ...
>>>> (a) Leave it up to the language
>>>> (b) Create a method on some object (like Window or Document)
>>>> that returns an
>>>> the object.
>>>> (c) Do it through DOMImplementation
>>
>> Ian Hickson:
>>> If you do either (b) or (c), please make it specific to that
>>> language
>>> binding and no _not_ permit a JS implementation to expose that API.
>>
>> Why?
>
> Because every single code path adds a new set of bugs, with its own
> set
> of Web pages that depend on it, with its own set of confused authors,
> with time spent implementing it, fixing it, testing it, etc.
>
> We already have at least three ways of obtaining an XMLHttpRequest
> object,
> we don't need a fourth.
On the other hand, for implementations that provide bindings to
multiple languages, it is a burden to exclude a particular API from
only one of them. (WebKit is such an implementation, we have an
Objective-C mapping to the DOM for use as part of the embedding API).
Here's a possibly too cute solution that would make things language-
independent but add nothing new for JavaScript:
interface WindowXMLHttpRequest {
XMLHttpRequest XMLHttpRequest();
}
In other words, require a function on the global object named
XMLHttpRequest which makes a new instance for you.
And for JavaScript allow it to be used as a constructor too.
In fact this fairly accurately describes what current implementations
already do.
Regards,
Maciej
Received on Friday, 7 April 2006 01:55:36 UTC