Re: No arguments to XMLHttpRequest.send (ACTION-58)

On Mar 2, 2006, at 2:26 PM, Jonas Sicking wrote:

> Jim Ley wrote:
>> "Jonas Sicking" <jonas@sicking.cc>
>>> I actually think that we should make the spec require an argument  
>>> for now. The whole purpose of this spec is to define what works  
>>> across all browsers so that users know what they can do.
>> I am against there being different behaviour in different methods  
>> defined by the Working Group, I'm open to the idea of always being  
>> required, but in that situation, we should always require  
>> parameters, having some methods e.g. .send( ) which you must  
>> specify null for and others e.g. .open() that are optional is  
>> simply confusing to users.
>
> Are users reading the spec or not, make up your mind ;)
>
> I don't think this is something that will confuse users, but rather  
> annoy them. Annoying API is aplenty in this spec though and  
> something I think we'll have to live with.
>
>> If the audience of the specification is users (which I don't think  
>> it is) and we do require it then the spec also needs to have an  
>> answer to the question of "why must I pass null?".    I don't  
>> think "buggy implementations" is an answer to that.
>
> While most authors won't read the spec I think some will. And more  
> importantly, the copy-chain has to start somewhere, probably at a  
> tutorial or reference site. And people writing those I'd think are  
> more likely to look at the spec.

I think the first version of the spec should limit itself to an  
interoperable subset of XMLHttpRequest that works in most major UAs.  
If there is some critical extra feature and someone responsible for  
that implementation can be convinced to add it, we could consider  
that as well.

For things that some but not all UAs implement, and that we'd like to  
require in a future version, we can add an informative note, or make  
it a MAY or OPTIONAL level requirement.

How does that sound as a general approach?

I thinkingthe no-arg version of send() would fall under this  
category. It does seem like something we want eventually, but could  
be MAY-level or an informative "some implementations allow this" note  
for XMLHttpRequest 1.0.

>  >> Things like minor inconsistencies in what onreadystatechange
>>> notifications are sent and how to resolve relative uris when  
>>> several windows are involved are things that I'm fine with since  
>>> it won't affect a lot of people. But send without argument would  
>>> probably be used by a lot of people so that is a lot worse.
>> getAllResponseHeaders( )  / getResponseHeader are also used by a  
>> lot, we're requiring them, yet many implementations don't have  
>> support.

Which are the implementations that don't have support?

> I'd suspect not nearly as often as .send(). I believe safari was  
> the only major browser that didn't support it, and if the safari  
> team wants them removed for now I could live with that.

We do have getResponseHeader and getAllResponseHeaders in Safari.

Regards,
Maciej

Received on Friday, 3 March 2006 00:48:05 UTC