See also: IRC log
Arvind: End of week, meeting in mountain view, date 10/5/2010, from noon to 5pm.
plh: may not be able to come for a subsequent 5hr meeting in Moutain View
Arvind: keep the 12-5 for the first f2f, get
agenda set by next week
... if we have enough items on the agenda extend the meeting to all day
... block out rooms at google for the entire day
Anderson: sounds great
Arvind: plh do you have advice to set the
agenda?
... already have the basic agenda to discuss the three specs
plh: we should discuss testing as well
Arvind: place to add agenda?
plh: can send agenda items to the mailing list
Arvind: mailing list is sufficient, with a link to a document
Anderson: comfortable with establishing the agenda over email, low overhead
Arvind: send an email to add to the list
plh: got lucky we got room, monday and tuesday
plh, nov 1st and nov 2nd, web apps working group will be meeting at the same time, one other thing, there is a fee to cover the costs. for each attendee register before oct 22nd
plh: fee after 10/22 is dramatically increased, costs rise for late
Arvind: potentially meet with the web apps
working group at tpac
... ask them for a slot to present
plh: everyone in the same room for a technical plannery day
Arvind: send email to web app chairs
<plh> see http://www.w3.org/Member/Mail/ for contact information
Anderson: send feedback to the email list for agenda items and goals for meeting in tpac before committing to attending
plh: one goal that can be satisfied with tpac is establishing test cases
Arvind: let's establish the agenda through the
email list for tpac and the f2f in mountain view
... let's get to item to 1 and 2
... let's start with the next set of items
Anderson: analyzed phases with tools
... look at it from the wire or the browser
Tony: some things are not present from the
browser perspective, do we consider, browser phase or network stack
... maybe answer is both, sending phase, network view, request phase from the
browser view
... the way the spec in webkit, reflects network view, the actual sending of
data, as opposed to time to get back
Anderson: the phases are broken down into browser work, sending request, waiting for server, first byte
Steve: browsers may be downloading of resources
before added to the dom, i can look at firebug netpanel and other tools and see
when the request was sent over the wire
... do not lose this ability in the web timing spec, as a web developer i have
no ability to measure how long it too on the network to download the jscript
file
... lump together may lose this interesting data
Nic: this conversation is intended to cover, the
requestEnd phase in the IE implementation the point that we get the first byte
back from the server, the webkit implementation is the browser has sent the
request from the browser.
... approach taken was that from the user agent point of view, there is a
consistent story across user agents.
... concern with perspective of sending the bytes to the server, some user
agents sit on an abstraction of the network layer.
... in IE, sits on the abstraction of browser, wininet, tcp. the browser may
not have insight into the lower layers.
... difference between the browser queuing the payload from when it actually
was sent out.
... responseStart is not the time the server sends the response, it's the time
the first byte was received in the browser. we are flexible for input.
... we want to make sure we can satisify the requirements as stated in the
spec and is consistent in user agents.
Steve: is there something in the spec that defines the requestEnd, when you're done with sending and receiving.
Nic: definition in spec: time user agent finishes request the current document from the server.
Tony: good time to have zhiheng on the call.
... get unique datapoint with different data point between requestEnd and
responseStart, capture that the user agent spends time uploading.
... not arguing one or another, key point to note here, is it important to
measure time spent uploading request. okay with the phase with get me this, i
got something back from the server.
Anderson: request phase can encapsulate a large upload. it captures a large upload and a long latency
Tony: Chrome network stack is re-written for
multiple platform capability.
... usually from the browser perspective, there is no insight, if this is
something to be difficult to implement, be interested to hear Mozilla's take.
maybe it's nto worth breaking out sending and waiting for server., be
interesting to hear mozilla's thoughts and zhiheng's thought.
... more parties need input here.
Anderson: value input from other user agents on this matter.
plh: can send emails to mozilla and apple if it helps?
Anderson: absolutely
Arvind: let's do that.
<plh> ACTION: plh to reach out to Mozilla and Apple [recorded in http://www.w3.org/2010/09/15-webperf-minutes.html#action01]
<trackbot> Created ACTION-4 - Reach out to Mozilla and Apple [on Philippe Le Hégaret - due 2010-09-22].
Arvind: next item is addtion of requestCount and uniqueDomains
Anderson: was introduced in the 3rd platform
preview, we would like feedback.
... provided to give top level information about the navigation, to decribe
dynamically generated pages, show total requests and show number of domain name
lookups
Tony: in absence of resource timing, may not be
necessary and duplicate resource timing. resource timing is going to be a large
topic, there's a lot of hard issues there.
... maybe it is useful to have something on the root document to expose
these.
Arvind: is there ambiguity how to compute requestCount and uniqueDomains.
Tony: need a point where these are lock down,
such as the point of loadEventEnd, or some point in the document, in the case
of dynamic additions of resources to the document.
... Can you desribe how it works in IE?
Nic: requestCount as we've talking about is the
count of scripts, images, css, objects, and iframes/subdocs.
... in our implementation there is no end point, it continuously updates. the
requestCount will continue to increment.
... similar to uniqueDomains, root document domain + unique domain, we
increment domains.
... added from feedback from web properties. this helps site developers gives
a characteristic of the page load.
Tony: these don't peer into subframes.
Nic: yes
Tony: if i have a resource in a redirect, it's only one request. i do like them, they may be redudant to resource timing.
Nic: good point.
Arvind: decide to include them or not?
Tony: present to Zhiheng, i have no problems adding them to webkit if they are in the spec.
Arvind: cover that next week.
... last item for today start discussion on resource timing and user
timing.
Anderson: want to cover the scenarios to cover in resource timing, i. access to resource timing, ii. access to resource timing from resources that have a different origin from the root document. With the constraint of not disclosing browser history to an attacker.
Arvind: can you put this on the email list?
Anderson: Yes.
Arvind: no items left.
Anderson: We've covered all topics.
Arvind: let's adjourn.