See also: IRC log
<scribe> chair: "JasonWeber"
agenda
list the agenda
Zhiheng: not sure if it is useful, I do not have a preference either way
NicJansma: thoughts about additional helper metrics for navigation timing?
Zhiheng: the value of the two attributes is marginal value
SteveSouders: why not lump it in
now, it makes sense to have it in navigation timing, it's a
state not specific about any resources, it's a stat about the
overall page
... if i take a step back, i would put these attributes in
navigation timing
NicJansma: that was our original
intention, to help describe why the page had been faster or
slower, the feedback is JasonSobel feels it not useful, however
not opposed. Nik Matsievsky from Webo mentioned he would value
these attributes.
... No privacy concern or security issue noted so far, may
require additional deeper dive. Not expensive to implement.
Tony: Not opposed, does resource timing make this redundant. if we add it now, we'll make sure it's not redundant.
Zhiheng: I have the same concern with Tony. If the resource fetched from cache, is that counted as request, that may reduce the value of what we are looking for and the bottle neck on the page. we need to work on the details on these two metrics.
Tony: If we do indicate if its from the cache we have concerns of privacy information.
NicJansma: IE9 have number of all the resources.
AndersonQuach: the two metrics complement each other.
SteveSouders: the attribute is called requestCount, sounds like network access. if the attribute is about resources, we should call it resource count.
NicJansma: We cannot split out resource that came from network or via cache, it would need to be appropriately named resourceCount.
Tony: this never decrements.
NicJansma: anytime thru an xhr, or img source, or get an external resource we increment by one.
AndersonQuach: next step, Anderson will propose the recommended text for the navigation timing to the spec.
NicJansma: do we think this has high value? or questioning it?
Tony: if we have a flat list of resource timings, like resourceTiming.length, however if we decide that we cannot have a flat list in resource timing. then i think it is high value. it's important information to convey. i much rather count the length of the resources.
SteveSouders: good point.
Zhiheng: adding a counter to resource timing instead.
SteveSouders: as the page is
loading we'll be adding things to the resource timing array,
and incrementing a counter. it would be better just to add
things on the array and get the length. i'll flip here, there's
a chance that this attribute has decreased value, redundant
with resource timing. there is a little bit of complexity
slowing down getting navigation timing out.
... i'm fine with omitting resourceCount from navigation
timing.
Zhiheng: in addition to what we have in resource timing, we can expose a counter to make it easy to get a resource count.
NicJansma: resourceCount / requestCount is a close fit to the length of ResourceTiming; what do you think about uniqueDomains, they can compute the # uniqueDomains on their own, it would be nice to provide that to them. is this something we can fit into navigation timing.
SteveSouders: recommend bundle them together and post-pone them until resource timing.
AndersonQuach: sounds like a plan, IE will update the RC to reflect the most stable version of the navigation timing
Tony: will we see window.performance or window.msPerformance
NicJansma: our goal is to have window.performance, as long as we get navigation timing to a stable point.
AndersonQuach: get to CR to drop the vendor prefix
Tony: what are the blockers?
NicJansma: major differences are uniqueDomains, requestCount, definition of requestEnd
AndersonQuach: work through the differences, stablize the interface and address the definitions in the spec to get the spec stable.
Tony: let's proceed without uniqueDomains and requestCount
Zhiheng: let's move requestCount and uniqueDomains to resource timing
NicJansma: sounds good
Zhiheng: get as much information
out of the timeline as much as possible.
... that seems like some problem in the implementation, do we
need responseStart if the definition of requestEnd be the first
byte of the server.
NicJansma: the thoughts in IE,
having start and end defined, ease communication. it would be
weird to have requestStart, requestEnd and responseEnd.
... we have start and stop for everything else, we don't have a
stop for fetchEnd or navigationEnd, other phases have very
similar timestamps. the time for the end of domain name lookup
is close / similar to establishing the connection. it does not
add a lot of overhead in the browser. it does help communicate
the overall picture. it will help the developer understand the
navigation.
Tony: what are your thoughts on measures and marks in IE?
AndersonQuach: in IE we will either vendor prefix or drop them for RTW.
Tony: we are leaning the way not having measures, i can echo what Nic says, it's nice for the developers, it looks like a measure, but you have to do the subtraction.
NicJansma: you can layout the
overall timeline with start-stop marks.
... having the full timeline from the marks will make it more
intuitive.
... we added it to the IE9 platform preview for feedback, but
we have not gotten a lot of feedback from the community about
this interface. if we decided to keep the measures, it may take
longer to get through the navigation timing spec.
... we put it in because we thought it would be easy to use and
useful for site developers.
SteveSouders: what's the definition to measures?
NicJansma: measures are the
subtraction of the timing phases defined in the marks. e.g. dns
measure is domainLookupEnd - domainLookupStart. easy to pack
and easy to JSON.stringify
... it only gives you the deltas of the phases not the full
details of the utc timestamps.
Zhiheng: seems like can omit in the measures for now and add the responseStart
NicJansma: that's my thoughts
AndersonQuach: as long as we can get to a uniform definition that is interopable to get a stable spec.
Tony: i like easily packable, i don't like redundant information. this is a grey close call. if all the users want to JSON.stringify to send it home. at this point, i really want to get to requestEnd, if marks in general should look like measures. wondering if starts and end should match up.
NicJansma: as a best practice,
provide a JSON library to pack up the timing measures that's in
a tightly packed structure, we can provide this type of sample
to the community, here's 20-30 lines of JScript that makes this
JSON array in a measure in a defined order.
... measure is redundant data.
Tony: Browser done its job to expose information that did not exist before, we do not yet what exactly is useful and we don't know what will be useful in the future. leaving measures up to the app is appealing to me.
NicJansma: we can always revisit measures in a future interface.
Zhiheng: we have an agreement here.
Tony: Are you okay with changing the definition of requestEnd == responseStart.
Zhiheng: if everyone agrees let's do it.
Tony: awesome.
NicJansma: we will work to get IE9 to get 100% conforming.
Tony: starting to feel
real.
... not sure what you mean about that? if you get a reference
to the frame, does the underlying object change?
NicJansma: good question, our testers pointed out. clicking a link and directs you to another page, the current page has the navigation timing object and initiating a new navigation. there is two navigation timing objects instantiated. in IE unload the last page only after we downloaded the new page, in the unload JavaScript even there is two navigation timings. the lifetime was not defined for the unload event. unload cannot pop-up dialog, cannot guar
Tony: they can make an img request
NicJansma: we do not make
guarrantee packaging and transmission of navigation timing in
unload, recommend to do it in onBeforeUnload.
... get your feedback on the lifetime.
Tony: in unload the current page
performance information is available.
... it would be strange to expose information for subsequent
page.
NicJansma: we don't want to do that's the wrong thing.
Tony: everything accessible in
beforeunload is accessible in unload. that's the way i
implemented the webkit version.
... is that difficult in IE?
NicJansma: there are technical challenges, but not a driving factor to what we want it to be.
Tony: if developers should not be doing much in the unload handler, they will try to ping this information back in the unload handler. i expect web developers to expect this to work.
NicJansma: one option is to access denying object in unload event.
Tony: i don't know how big the technical objects. webkit, everything is ref counted. if it's really hard. i would not be opposed to exploring other options. however, it should be accessible.
Zhiheng: is there anything blocking to releasing the navigation object in unload.
NicJansma: currently in the IE9 beta, future timing is started to be exposed in unload event, this can be worked around. we wanted to define the lifetime.
Zhiheng: we should keep the current browsing context in unload before populating the target / next browsing context in unload.
AndersonQuach: need to provide a constraint that the timing is relevant for the current browsing context in all events
Zhiheng: if i have JScript getting the timing object in the unload, what timing object are we getting.
Tony: in the current page, webkit
has two timing objects in unload. the target navigation's
timing object is not accessible in the current page's
unload.
... look for any property in the window object, language or
pattern to indicate properties of window object should have
Zhiheng: i'll check it out
AndersonQuach: sounds like a good plan
list the agenda
Zhiheng: good shape
Tony: we solved the first three we have consens
agenda 12
move to agendum 12
AndersonQuach: i'd like to propose review navigation timing, and review the intended reference implementation in IE9 and in Webkit, thoughts?
SteveSouders: those sound good to
me. focusing on things that are better face to face than over
email.
... we can work on examples, we may have a 30 line snippet for
javascript, use the timing and becon it back. work on
recommended sample snippets. may iterate faster live. add code
samples.
AndersonQuach: agreed
Tony: great time to draw a straw man for the resource timing and user timing.
AndersonQuach: can use the time to dive deeper in ResourceTiming.
Zhiheng: let's bring up these issues in the face to face meeting.
NicJansma: do we want to tackle user timing in the f2f or the next conference call.
SteveSouders: let's talk about it on the conference call a little bit. i would add both of those tenatively to the agenda for the f2f. we should figure out which is more important.
NicJansma: sounds good let's talk about it next week's conference call.
Zhiheng: if we can come up with the initial draft of user timing before the face to face.
AndersonQuach: i'll sign up for that.
move to agenda 13
NicJansma: additional business?
Zhiheng: sounds good.
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: AndersonQuach Inferring Scribes: AndersonQuach WARNING: No "Topic:" lines found. Default Present: [Microsoft], Zhiheng, +1.650.823.aaaa, +1.650.214.aabb WARNING: Replacing previous Present list. (Old list: "SteveSouders") Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ "Tony" Present: "Tony" WARNING: Fewer than 3 people found for Present list! WARNING: Replacing previous Regrets list. (Old list: "Arvind") Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ "JasonWeber" WARNING: Replacing previous Regrets list. (Old list: "JasonWeber") Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ "plh" Regrets: "plh" Got date from IRC log name: 22 Sep 2010 Guessing minutes URL: http://www.w3.org/2010/09/22-webperf-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]