[whatwg] Appcache feedback (various threads)

On 2/1/11 11:47 AM, Adam de Boor wrote:
> On Mon, Jan 31, 2011 at 3:28 PM, Ian Hickson<ian at 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

Received on Tuesday, 1 February 2011 09:34:15 UTC