On 2/1/11 11:47 AM, Adam de Boor wrote:
On Mon, Jan 31, 2011 at 3:28 PM, Ian Hickson<i...@hixie.ch> wrote:
On Fri, 13 Aug 2010, Patrick Mueller wrote:
On 8/12/10 6:29 PM, Ian Hickson wrote:
On Wed, 19 May 2010, Patrick Mueller wrote:
I've been playing with application cache for a while now, and found
the diagnostic information available to be sorely lacking.
For example, to diagnose user-land errors that occur when using
appcache, this is the only practical tool I have at my disposal:
tail -f /var/log/apache2/access_log /var/log/apache2/error_log
I'd like to be able to get the following information:
- during "progress" events, as identified in step 17 of the
application cache download process steps in 6.6.4 "Downloading or
updating an application cache"), I'd like to have the URL of the
resource that is about to be downloaded. The "progress" event from
step 18 ( indicating all resources have been downloaded) doesn't
need this.
What do you need this for?
See the first sentence: diagnostic information.
Surely if you want to debug the appcache update mechanism it'd be easier
just to have the browser provide you with a dedicated debugging tool for
it than for the browser to provide you with more information in an event.
As an example, an application might collect a log of errors and post
them back to a server for diagnostic purposes later. Not possible if
the only way to get app-cache diagnostics is with a "web debugger".
That rather depends on the debugger.
The one concern I'd add to this mix is cache installation in the presence of
funny network environments, specifically misbehaving proxies, or browser
extensions / plugins. As an app developer, it's always helpful to have as
many tools as possible to debug problems that happen in the wild. For a
supposedly-standardized environment like the web, it's amazing to me how
many there are... It's feasible to have a small set of users click something
to create a log file they can email you, but asking them to fire up the
debugger in their browser? No.
Yes, that was my intention - not something for web developers, but
something I can put in my code that would collect diagnostics that I
could report to the user ("problem with cache file: xyz.abc").
I just tested Chrome beta this morning and saw nothing interesting in
appcache error events, however progress events have now grown "loaded"
and "total" properties (think those were the names, and I think they're
new-ish). That's nice, as I can provide a progress meter during cache
load/reload. I wouldn't mind having the URL of the resource being
loaded (that was just loaded?) as well as those numbers. And for errors
it would be nice to know, in the case of an error caused by a cache
manifest entry 404'ing (or otherwise unavailable), what URL it was.
HTTP error code, if appropriate, etc.
Cache resources that aren't available is a particularly nasty issue,
since the result is rather heavy-handed - the entire cache reload is
canceled. That's fine (or a fight for another day anyway), but it would
be nice to know WHY the cache reload failed. Programmatically. Today,
all we know is it failed. The browser knows WHY it failed, but has no
way to inform us, outside of an appcache-grokkable debugger.
--
Patrick Mueller - http://muellerware.org
