Ilya: how do we want to proceed to land it in performance timeline description?
... I'd like to be more thorough on how events are recorded
https://github.com/w3c/performance-timeline/pull/10
scribe: when do we emit the records?
... ie, initialize the entries, append it to the buffer, ..., and then deliver it to the observer once it's finalized
plh: that means the NT record would be submitted after the loadevent is completed
Todd: agree that entries should only appear once they're completed
... RT and NT entries appear before their entries are filled. was it intentional or not?
Ilya: by product of implementation
... suspect we can't change it
Yoav: also use cases to estimate network performance
... earlier is better
Ilya: we shouldn't make promises that these entries are synchronous. we want to move the devs away that should rely on delivrance of the entries
... no guarantee it will be after the delivery of the resource
Yoav: use case is network estimation
... hard time to expose network information to developers
... having that info early on will allow to do bandwidth estimates
... and use different loading logic based on result
... not sure if it's the best tool to do that
... if it relies on implementation details, I agree we shouldn't expose it
Ilya: next step? merge the PR and iterate?
Todd: agreed
Ilya: I'll merge the PR and start a new one then
Plh: can we publish and get more eye balls?
Resolved: ok to publish a FPWD for Performance Timeline 2
https://github.com/w3c/resource-timing/pull/19
Ilya: current spec doesn't say anything on failed fetches
... we should surface them
... if http server broke, dns would be there but remaining empty
todd: Edge surfaces most of them, just a couple of exception
Plh: ok to merge?
Todd: yes
Yoav: what about redirect?
Ilya: I'll open an issue on resource timing then
https://github.com/w3c/navigation-timing/issues/11
Todd: I'll take that one
Ilya: can we have guidelines for editing the html in webperf?
Plh&Todd: sure
Ilya: resource hints: removed loadpolicy and have prefetch/prerender
... we're now adding optional attributes
... the probability attribute
https://github.com/w3c/resource-hints/pull/27
Ilya: can we merge this one?
All: ok
https://github.com/w3c/preload/pull/17
Ilya: one issue with fetch at the moment. the as attribute will be passed to fetch
Yoav: not sure why why the response has to be tainted in the context
... what's blocking this from having as set a context that is different from the fetch context?
Ilya: if there is a CSP policy with "only img from host", you shouldn't be able to circumvent the policy
... we're stuck on the appropriate header and other settings
... for preload, we could block on that
... or put some clause in the spec and merge
Yoav: we don't have to block in terms of implemetations
... for preload, as can do whatever we think it's right
... I don't think the circumvention applies to preload
Ilya: preload just do a cache thing and then it gets enforced when used by other elements
Yoav: ok we can put a place holder in the spec
Ilya: I'll clarify that
... and then merge 17
Resolved: FPWD for preload
https://github.com/w3c/performance-timeline/pull/9
Ilya: thinking we can ignore that one. original proposal was to have a common id
... but folks would like to see a more general purpose mechanism
... ie group by properties
... e.g. getEntries(site, value)
Todd: make sense, looking at the use cases
Ilya: for frame timing, we have a source frame number
... for things like redirect, we'll have to create a fetch id
Plh: did you talk to Anne about the idea of fetch id?
Ilya: nope
... that's pseudo-code
... same return value as getEntriesByType
plh: how about getEntries({type: entryType})
... getEntries({type: entryType, name: entryName})
Todd getEntries({type: 'resource'}) to get resource timings
plh: what about getEntries({foo: "bar", type:"resource"}) ?
Ilya: would return empty list
... I'll close PR9 and open a new one
http://www.w3.org/2010/webperf/board/
plh: we're not making progress on our backlog of issues. let's elect issues in upcoming calls so we can move forward.
Ilya: talked to Hixie about adding some mechanism and he is ok if we can get a +1
<igrigorik> https://lists.w3.org/Archives/Public/public-web-perf/2015Apr/0005.html
Todd: I'll go talk to Travis and see if we can +1 this
Plh: next one in two weeks