Re: First Public WD of XMLHttpRequest released

"Anne van Kesteren" <annevk@opera.com>
>> I don't see why responseText MUST be null other than in readyState 3 or 
>> 4, why not undefined (e.g. if the firing of the 2 is delayed for some 
>> reason then data could be available) Equally MUST on 3 is incompatible 
>> with existing implementations.
>
> It's never null. If the firing of the 2 is delayed, isn't that just a bug?

No, we're not mandating that events fire in realtime - we can't as ES is 
single threaded etc.

> The "MUST on 3" is incompatible with existing implementations in what way?

MS's XHR implementation throws an error on 3.

>> alert( ) isn't defined anywhere, traditionally print has been used as a 
>> dummy function in ES code.
>
> Any pointers of its use?

The ES spec, just changing alert to print...

>  by data.xmlEncoding, if specified and supported, or UTF-8 otherwise
>
> Makes some sense to me...

I still don't see the point of the restriction at all, and inputEncoding 
would be a better option than xmlEncoding  - if we're assuming the server 
knows the best format for a document serialisation, but I don't see the 
point of requiring such behaviour.

 > Responded to this one already. In addition, we now have an open issue on
> it.

Cheers!

Jim. 

Received on Thursday, 6 April 2006 09:52:47 UTC