- From: Patrick Mueller <pmuellr@muellerware.org>
- Date: Fri, 13 Aug 2010 09:18:13 -0400
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
Received on Friday, 13 August 2010 06:18:13 UTC