ToddReifsteck: we should wait for plh@ for right steps to do a crisp handoff
... we should ask plh@ how to handoff outstanding issues
AI: we'll wait for next call with plh@ to resolve this one
mpb: any concerns over visited, does that need to block FPWD?
ToddReifsteck: doesn't need to block, we can publish FPWD
igrigorik: I'll check if we can publish, might need plh to flip right bits
<ToddReifsteck> https://github.com/w3c/navigation-timing/pull/32
ToddReifsteck: no objections, will merge
Next item: https://github.com/w3c/frame-timing/issues/46
<ToddReifsteck> Upcoming: https://github.com/w3c/performance-timeline/issues/41
<ToddReifsteck> Upcoming: https://github.com/w3c/performance-timeline/pull/43
mpb: keeping them separate allows us to add different attributes in the future (something we discussed but don't have today.. yet)
eliperelman: the paths to both of them are very different, there might be some associated overhead..
ToddReifsteck: we can add the counter event interface in the future if we get a 3rd or 4th
... wontfix, will followup on the bug
<ToddReifsteck> Next item: https://github.com/w3c/performance-timeline/issues/41
ToddReifsteck: thinking is.. if PO has ability to report existing timeline then JS interface is much simpler (no races)
... same thing is possible via other means but we need a crisp processing model
some issues: lookback doesn't play well with our current buffer model; we should nail the processing model first
mpb, eliperelman: there is potential for missed events (e.g. exceeded buffer)
looking at Chrome, changing buffer size is very rare
mpb: a plausible v2 enhancement?
https://github.com/w3c/navigation-timing/issues/1
<ToddReifsteck> https://github.com/w3c/performance-timeline/pull/43
ToddReifsteck: we should nail down the processing model, we'll resolve current issue as possible future enhacement
any objections to going back to "new PerfObserver" approach?
ToddReifsteck: no, we should iron out the language questions and get Anne/Boris to sign off
Eli: no objection
mpb: we'll follow up on the thread
<ToddReifsteck> https://github.com/w3c/beacon/issues/10
http://w3c.github.io/beacon/#sec-processing-model
<ToddReifsteck> https://github.com/w3c/beacon/issues/5
Re, #10: igrigorik to followup, current spec is already defined via Fetch
Re, #5: we'll define Beacon-Age, the similar use case for NEL is no longer relevant because NEL can deliver multiple reports in same payload
<ToddReifsteck> Preload: https://github.com/w3c/preload/pull/26
<ToddReifsteck> 8/26 for next call