See also: IRC log
<scribe> scribe: Jatinder Mann
Jatinder: Options are to either
keep the NavigationStart and RedirectStart zero'd out for
redirect case (current approach, previously agreed on)
... Or show NavigationStart for all cases, or clear out
NavigationStart and RedirectStart for cross-domain cases.
Zhiheng: Developers may want to use NavigationStart to monitor percieved latency due to cross-domain redirects.
Nic: Cases when you're coming from a different domain, doesn't seem like a compelling reason, because site owner can't do anything. But in the sub-domain case, the developer can make changes to improve things.
Zhiheng: People can already use
cookies to determine starting of navigation. There are similar
cases.
... Might not be a good example, but a developer could already
estimate the NavigationStart time. They could use an
iframe.
Nic: Navigating from another site, there is no way to get that information. My biggest concern is showing NavigationStart is the same as showing RedirectStart.
Jatinder: It's a trade off
between a feature and security. We need to determine whether
the feature is worth more or if the security concern is less of
a concern.
... Let us follow up with our security experts and see if the
security issue is really an issue.
... We can get back to the thread with this information. If
it's not a threat, we can opt into the feature. If it is, we
should find a solution that balances security with
usability.
Zhiheng: Okay, sounds good. I
will look up for old information on this topic.
... Once we have that information and security, we can discuss
this more.
http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/
Jatinder went through the changes made to the Resource Timing spec.
Folks will review the changes and give feedback on the mail thread.
URL to test cases: http://w3c-test.org/webperf/tests/submission/Microsoft/NavigationTiming/
Tony: We'll review the test cases and respond in mail.
Nic: How are we going to manage test case changes when changes are made to the spec?
Zhiheng: If we change the spec, we should also run through the tests and see what things break.
Nic: Are there major areas that we should look to submit new test cases?
Action Zhiheng to follow up on test coverage and propose new test cases.
<trackbot> Created ACTION-18 - Follow up on test coverage and propose new test cases. [on Zhiheng Wang - due 2011-04-13].
Nic: We spoke briefly about including the HTTP status code, what are the thoughts about bringing this in?
Zhiheng: What is the security concern of doing this?
Nic: We're only returning the
last status code, so the concern may be mitigated.
... Not sure what developer scenarios would this impact.
Tony: For developers point of
view, it may be useful to see the status codes. But we have
stayed away from showing information in the cache. We would
probably need to follow the cross-origin rules.
... The status codes can imply when you're in the cache.
... You can get this information from your server logs anyway.
It may nice to get this, but if its going to be
complicated...
Jatinder: What are all the scenarios this would enable?
Nic: We should decide whether or not this is a worthwhile feature. We may want to see if there are any consumers for this feature and consider it later. There will be cross-domain issues we'll need to solve.
We've decided to punt on this feature as there isn't a particularly convincing scenario that we can imagine. Considering there will be cross-domain complications that would need to be solved, we should only consider this feature if there is a particular ask for this.
Tony: Have you considered the James’ proposal?
Jatinder: What are the benefits of that proposal? I don’t think I understood the main difference.
Tony: The problem with the current approach is we seem to be recreating the DOM tree with the id attribute.
Nic: What if we didn't include
the id attribute?
... We may want to clarify that the current API is not like a
DOM API, by cutting the getResourceById and
getResourceByType.
Tony: That's interesting. That
may resolve some of the concern.
... What about extensibility? The current model requires
updates to the namespaces, etc.
Nic: With our aggressive schedule, it may make sense not to consider major changes unless there is signifcant value.
Jatinder: Let us follow up and look at the proposal more carefully and give both pro and con feedback on the mail thread.
Tony: That seems like a more productive approach.
Jatinder: Considering User Timing has the same deadlines as Resource Timing, let's spend some time next call discussing feedback on the User Timing spec. Please feel free to email the thread with any feedback on that spec.
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) No ScribeNick specified. Guessing ScribeNick: Jatinder Found Scribe: Jatinder Mann Present: Nic Jansma Jatinder Mann Christian Karen Anderson Zhiheng Wang Tony G James Simonsen WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 06 Apr 2011 Guessing minutes URL: http://www.w3.org/2011/04/06-webperf-minutes.html People with action items:[End of scribe.perl diagnostic output]