7784 2009-10-01 13:43:01 +0000 "cache failure steps" feedback 2010-10-04 13:58:22 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Linux RESOLVED FIXED NE P2 normal --- 1 annevk ian ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 27970 0 annevk 2009-10-01 13:43:01 +0000 Should the status be changed before dispatching the error event? That would be more consistent with when the checking and downloading events are dispatched. (I also get the feeling it would have been better if we had separate states for networking and the cache, but I guess that is not going to work at this point.) It would be nice to have a note at step 7 ("If this was a cache attempt, discard cache group altogether.") that indicates this will change the state of the object the API talks against to UNCACHED. 28486 1 ian 2009-10-18 23:39:48 +0000 The status can't be changed to 'idle' until the last step, otherwise you'll have a race condition where two instances of the algorithm are running at once. I've made the spec clearer that the tasks are expected to hold off until the next few steps are run also, though. I didn't mention the API in the algorithm because it would be the only mention of it which seems kind of weird. Not sure what it would add. Please feel free to file another bug for that though if you feel strongly about it. 28487 2 contributor 2009-10-18 23:40:16 +0000 Checked in as WHATWG revision r4172. Check-in comment: Get rid of a potential race condition in the cache update process. http://html5.org/tools/web-apps-tracker?from=4171&to=4172