- From: Michael Nordman <michaeln@google.com>
- Date: Thu, 29 Nov 2012 13:36:30 -0800
- To: David Barrett-Kahn <dbk@google.com>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
Sounds reasonable to me. Webkit and chromium expose information like this via the inspector console so users/developers at that can better diagnose problems locally. Makes sense to also expose that info to app logic so developers could diagnose from afar. On Thu, Nov 29, 2012 at 11:40 AM, David Barrett-Kahn <dbk@google.com> wrote: > So are there no objections to this, should I draft a change to the spec? > > -Dave > > On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn <dbk@google.com> > wrote: > > > Right now this event contains no structured information, just an error > > message. It'd be helpful to us to know more about what failed, so we can > > know what to report to the server and take action on. It's hard to > > distinguish cache update failures due to just being offline from those > > which are actually causing trouble. In the second case it's also hard to > > work out which resource is proving unavailable and why. > > > > One way to do this would be to create an AppCacheError subclass, with an > > errorCode parameter, and also nullable url and httpResponseCode > properties. > > Potential error codes: > > * couldn't fetch manifest (includes url and httpResponseCode) > > * pre and post update manifest fetches mismatched (includes url) > > * fetching a resource failed (includes url and httpResponseCode) > > > > Related bug: > > https://code.google.com/p/chromium/issues/detail?id=161753 > > > > Thoughts? > > > > -Dave > > > > > > > -- > -Dave >
Received on Friday, 30 November 2012 00:05:25 UTC