- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 26 Sep 2008 16:25:10 +0200
- To: "Anne van Kesteren" <annevk@opera.com>, "Jonas Sicking" <jonas@sicking.cc>
- Cc: public-webapps@w3.org
On Thu, 25 Sep 2008 19:12:54 +0200, Anne van Kesteren <annevk@opera.com> wrote: > On Thu, 25 Sep 2008 19:01:57 +0200, Jonas Sicking <jonas@sicking.cc> > wrote: >> We'd also need to do it if 'load' has been registered. I would in >> general say that we should force it if any events have been >> registered. That will make it more compatible with future versions of >> the AC spec. For example say that a future version of the >> ProgressEvents spec adds a 'redirect' event or a 'stalled' event we'd >> want to force preflight as well. > > Fair enough. Made change to the specification. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ (Currently labeled as WD since we're publishing next Tuesday.) > Then I'll specify the former as special casing those methods here is > something I rather not do. I'd much rather have addEventListener, > addEventListenerNS, onprogress, etc. work consistently. I've done it this way. The 'progress' and 'load' events are only dispatched if a preflight request has been made. >> Looks great. The only thing I'd add is to be more explicit around the >> initial description of the cache that each cache entry always has >> exactly one of 'method' and 'header' empty and the other non-empty. >> I.e. that either of them always exist, but never both. > > Ok, will fix that tomorrow. Got to go now. Added a note explaining the fields are mutually exclusive. Would it be useful to note that (origin, url, method, header) form the primary key of a cache entry? Since it's never needed by the specification in that way I didn't add it, but let me know. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Friday, 26 September 2008 14:25:48 UTC