108907 - Freeze XMLHttpRequest interface

Status: RESOLVED WONTFIX

(Core :: XML, defect, P2)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Must freeze this interface to let developers rely on it. Since it is copied from
a stable Microsoft interface should be relatively easy. Must get rid of
nsIChannel from the interface, and freeze all other interfaces that are required
by this interface as well as the ones those require and so forth. All in all
maybe about 10 DOM interfaces plus this one.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Need to freeze:

nsIXMLHTTPRequest
nsIOnReadystatechangeHandler
nsIJSXMLHttpRequest
http://lxr.mozilla.org/mozilla/source/extensions/xmlextras/base/public/nsIXMLHttpRequest.idl

nsIDOMDocument [status FROZEN!]
http://lxr.mozilla.org/mozilla/source/dom/public/idl/core/nsIDOMDocument.idl

nsIDOMEventListener [status FROZEN]
http://lxr.mozilla.org/mozilla/source/dom/public/idl/events/nsIDOMEventListener.idl

nsIVariant
nsIDataType
(nsIIDPtr, nsQIResult, voidPtr, nsIID, nsID ?)
http://lxr.mozilla.org/mozilla/source/xpcom/ds/nsIVariant.idl

Need to get rid of nsIChannel. I think the only user was the IBM P3P code. Am I
right?

MS has two more members, responseBody and responseStream. Not sure what to do
with them yet.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk30/htm/xmobjxmlhttprequest.asp

Comment 2

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Attachment: Remove nsIChannel, add status FROZEN

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

valeski gave me this URL as a poor man's guide to what is required for an
interface to become FROZEN:

http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html

He also noticed that the name should change to nsIXMLHTTPRequest (notice all
upper case HTTP). I am not too happy about that, but...

nsIVariant is in need of some documentation.

Interfaces should go one in each file.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Adding valeski & vidur... I have a couple of questions to valeski and vidur
might have something to add as well.

1. Is it an absolute must that all interfaces be in separate files? In the case
of XMLHttpRequest there are three, but from JS there is logically just one (a
combination fo them all). nsIVariant also has several that in my opinion belong
into one file, except maybe for nsIWritableVariant.

2. I see changing the name very problematic at this point: it shipped with
Netscape 6.1 so there are likely to be sites using this. Should we make it a
warning in strict JS to use the old style, and also introduce XMLHTTPRequest? I
am not even sure if this is possible...

Finally a note to myself, all Mozilla extensions to XMLHttpRequest should be
clearly marked as such with comments.

Comment 5

[Judson Valeski]

1. one iface per file isn't a hard and fast rule, rather, its a good guidline to
follow. if there are 'n' ifaces in a single .idl file, they at least needs to be
logically related, and the chances of someone needing to use all of them
together should be pretty high. the point is, if I only need nsIFoo, I don't
even want to have to see nsIBar (unless I really need to).

2. If the name change is too painful, let's avoid it.

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

It seems there is pressure to still change nsIVariant. It is also relatively new
interface, so it seems to be unclear when it would be ready to be frozen.
Eventually it should be, as I think it is one of our "fundamental data types",
so to speak.

This got me thinking that we currently do not have a process to freeze the
interfaces that JS only sees (and not worry about C++). I don't know if there
should be. It would be a lot easier to freeze XMLHttpRequest's "JS interface".

I am starting to think this freeze should happen post-1.0...

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Later, although I might remove nsIChannel anyway...

Comment 8

[Wladimir Palant]

Please consider bug 218236 when deciding whether to remove nsIChannel. The only
workaround I could find is checking the channel every second - there is no other
way to know that the request is completed.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Lets not do this. We're planning on no longer freezing interfaces, and this one is still having features added to it.