[whatwg] Appcache feedback (various threads)

[Patrick Mueller]

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.

>> - for all error conditions, some indication of WHAT error occurred.
>> Presumably an error code.  If the error involved a particular resource,
>> I'd like the URL of the resource as well.
>>
>> I'm not sure what the best mechanisms might be to provide this info:
>>
>> - extend the events used to add this information
>>
>> - provide this information in the ApplicationCache interface -
>> lastErrorCode, lastResourceDownloaded, etc
>>
>> - define a new object as the target for these events (currently
>> undefined,or at least not clear to me), and add that info to the target
>>
>> - something else
>
> Could you describe how you would use this information? What would you do
> differently based on this information?

again: diagnostic information.

Of course, there's not much I can "do" differently, based on this 
information, since there's little I can "do" with app-cache to begin 
with, being largely declarative.

I understand the typical response here is: use a debugger.  That's fine, 
and that's right, for most of my purposes, but means I'm relying on a 
tool to get information, that a normal application might not be able to 
retrieve.

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".

There's a good argument for not providing this information, I suppose: 
you can't get it for non-app-cache scenarios, why should you get it for 
app-cache scenarios?  (I'm assuming here that you can't get 
HTTP-transport level information from anything but XHR, WebSocket, etc 
sort of APIs - you don't get that sort of information about a .css file 
you referenced in your .html file, for instance).

Additionally, are there security issues that I'm not aware of (haven't 
though enough about)?

None-the-less, we do have these nice events coming in, there's plenty of 
room for more information in them, and they would serve a useful purpose 
since app-cache has proven, to me, to be an occasionally challenging 
corner of the room to play in.

-- 
Patrick Mueller - http://muellerware.org