W3C home > Mailing lists > Public > public-webapi@w3.org > May 2007

Re: [XMLHttpRequest] Request for Last Call 2

From: Stewart Brodie <stewart.brodie@antplc.com>
Date: Tue, 8 May 2007 12:20:21 +0100
To: public-webapi@w3.org
Message-ID: <e1c2767094cb4e486fd37f2e1daeafcd530f5224@localhost>



Re: the 8th May draft at
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8


I like the reworking of the method descriptions to specify things
algorithmically.  However, I do not understand what is going on in the
send() method.

The send() event seems to have changed considerably since the previous
drafts that I saw.  I think that you need more explanation for the bizarre
readystatechange event during step 5 of the send() algorithm since, as the
note points out, the state hasn't changed.

I do not understand why the transition to state SENT is so complex.  In my
current implementation, calling send() (in such a way that no errors occur)
results in the state being set to SENT immediately and a single
readystatechange event being raised.

I think the above point may be answerable by providing a definition for "has
been successfully acknowledged" in step 7.

Is the purpose of the "send() flag" simply to cover the period of time
between the invocation of the send() method and the transition to state
SENT?  Why is there a period of time during which this can occur?



My implementation cannot work synchronously - and such operation is highly
undesirable in embedded devices anyway.  Currently, this is dealt with by
raising NOT_SUPPORTED_ERR in the open() call when the async parameter is
passed as false.  I can see that the converse may be true for other agents.
I think that implementations should be given this option.



I don't think you can leave open()'s step 10 dangling without a definition
of what the same-origin policy is, particularly since the document does now
link with the Window object document via which the base URI will be obtained
for the purposes of comparing the two URIs.  This is likely to cause
compatibility isues if different implementations use different rules.
However, I'd also like a get-out that permits user agents to suspend the
application of same-origin policy rules - or override the policy decision -
in circumstances that the UA defines.  I want the trusted content in my
(closed) system to be able to access anything it likes.



In the events section, what would it mean for an event on an XHR object to
bubble anyway?  Bubble to where?  What about the Capture phase - what other
objects will see the event?  I suppose this is more of an issue for the DOM
Events specification that here, though.



Finally, there's a typo in step 8 ("receieved")


-- 
Stewart Brodie
Software Engineer
ANT Software Limited
Received on Tuesday, 8 May 2007 11:19:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT