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
