[minutes] Web Performance WG Teleconference #104 2013-04-03

Meeting Summary:



1.     Diagnostics and Error Logging

In this week's conference call, we discussed the Error Logging specification, https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ErrorLogging/Overview.html. There were two areas of discussion on this spec area raised in the mailing list: (1) monitoring and error logging, (2) real time notification of errors. We discussed issue #1 on the call this week.



Based on the today's conversation, we want to have a separate object for historical error data that only specifies document errors, and an object for current errors that specifies document and resource errors. We also wanted the spec to be clear that historical error data will be persisted. I'll make spec updates for next week's discussion.



We also wanted to review the list of errors types that we should specify. Dan will be sharing a list of errors that we should consider in next week's call.



2.     Charter

Please make sure to have your AC reps respond to the survey on this working group's charter.



3.     Agenda for next week's call

We will continue our discussion of the Diagnostics and Error Logging specification next week. In particular, we will review the error type data and also discuss real time notification of errors.




W3C Web Performance WG Teleconference #104 2013-04-03



IRC log: http://www.w3.org/2013/04/03-webperf-irc



Meeting Minutes: http://www.w3.org/2013/04/03-webperf-minutes.html



Attendees

James Simonsen, Jatinder Mann, Daniel Austin, Ganesh Rao, Alois Reitbauer, Arvind Jain, Aaron Heady, Philippe Le Hegaret


Scribe

Jatinder Mann



Agenda

1.     Discuss Diagnostics and Error Logging

2.     Discuss Charter updates

--------------------------------------------------------------------------------



Minutes:
Diagnostics and Error Logging
Jatinder: Based on the mailing list, there are two areas of discussion on this spec area: (1) monitoring and logging of errors, (2) real time notification of errors.
... Let's talk about each of these aspects.
DanAustin: Will the spec clarify how the user agent plans to persist this data? Cookies or other storage mechanisms?
James: We should specify that the browser will persist data across sessions. But we don't need to specify what exactly the mechanism it is.
DanAustin: I think the spec should at least specify that data is persisted.
Jatinder: I'll make the change.
Ganesh: How long is the data persisted?
Aaron: Currently, there is a FIFO buffer about 150 entries large.
<plh> we can ping the Privacy Interest Group as well, re multiple sessions handling
James: Should we seperate out resources from previous sessions?
Aaron: There is benefit in having all the resources data available.
James: I want to make sure that we don't allow the origin tracking users. E.g., looking at the error history, I can see when the user had been visiting the site.
Aaron: We may want to specify that when the cookies aren't logged, we shouldn't log information.
James: I think that should help.
Jatinder: We should follow up with the privacy folks and see if they believe we need this restriction. But I think we should definitely track this.
... Did anyone have feedback on the attributes specified?
DanAustin: I had taken an action item on putting together a list of errors. From Ebay's point of view, we use a lot of synthetic tools like Gomez, Keynote, and others. I took a look at those errors and propose that we put together something similar. And we should probably follow up back with the tooling folks.
... I'll send out an email with a list of errors.
Arvind: Should we track the abandonment rate as well? E.g., when you deliver a 500 error, you are aware. But what about the case when the page is loading slowly and the user hits reload midway.
DanAustin: There seems to be value in knowing when the user aborts the page. From a business point of view, you may want to see why the user chose to leave the page or reload.
Aaron: Yes, you could even find out if a certain locale is having a problem.
Jatinder: I think we should add abandonment / abort on the error list.
DanAustin: I'll put it on the list.
Arvind: I want to talk about network error data vs. resource error data. What's the benefit of having resource error of historical sessions? Can't we just send that data up in the current session?
Jatinder: For Navigation, Resource, User Timing, the interface stored data for the current session. Sites can use JS to upload that data. We only considered making the change to support past sessions for the case where the document failed to load. If that is the bar, I agree that we should only store resource data for current sessions, and store only document error data for historical sessions.
James: I think the startType attribute will be confusing for the historical data, as it may overlap in the current timeline. I think we should have a seperate object for historical data.
... Historical data should have a zero'd out startTime.
DanAustin: Would the historical data include information like how long it took for the DNS to occur? That's useful data when attempting to fix an issue.
Aaron: Because we have a seperate object for historical data, we can add more information.
Jatinder: That's good feedback. I'll update the spec to have two different objects, one for the current session and one for historical sessions.
... Since we have run out of time, let's discuss the real time notification of errors in next week's call.
Charter
Philippe: I am still waiting for the AC reps from folks participating in this working group to sign off on the new charter. I will push out the charter sign off date until next week. Please be sure to have your AC reps respond.