[re getting an XMLHttpRequest object]
What about non-ECMAScript implementations?
If you want to worry about non-ECMAScript implementations (which may
conflict with "The goal of this specification is to document a minimum
set of interoperable features based on existing implementations", but
perhaps it's a good idea to allow other languages from the start), then
you will have to provide a mechanism for getting a new XMLHttpRequest
object that doesn't rely on ES-specifics such as calling [[Construct]]
on some function object. Some interface would have to provide a
function that creates an XMLHttpRequest, such as
interface WindowXMLHttpRequest {
XMLHttpRequest createXMLHttpRequest();
}
and then objects that implement Window could be required to implement
WindowXMLHttpRequest if the implementation supports XHR (assuming Window
objects are the most appropriate for this; what would be the
alternative, DOMImplementation?).
I don't think Windows are the place to put a bootstrapping function. The
only argument I can see for putting it on Window objects is that it is
the global scope, however that is only the case in ECMAScript and in
ECMAScript bootstrapping is done through |new XMLHttpRequest()|.
DOMImplementation would make some sense though.
However, I don't strongly feel there is a need to have a unified
bootstrapping process. Bootstrapping has to be language specific since
even if you add a bootstrap for method on some object you are left with
having to define a way to get to that object. I.e. the more
bootstrapping indirection you add the more cumbersome it gets to
instantiate objects and the problem will always remain anyway.
And creating objects is something that works vastly different in
different languages. While |new XMLHttpRequiest| makes sense in
ECMAScript,
|do_CreateInstance("@mozilla.org/xmlextras/xmlhttprequest;1")| makes
sense in XPCOM.
However, I come from a browser world, so I'm probably biased.
/ Jonas
