We're blocking this on shipping takeRecords.

It's unclear how this is related to https://github.com/w3c/resource-timing/issues/141.

Punting for now.

Hey Tim - any update on this? Stumbled across it during my CSM triage rotation, and it looks like it's been "started" for a while now.

Nicolas, I forget where we landed on this.

I think we should probably ship this soon, but I seem to remember you thinking the opposite?

Per https://chromium-review.googlesource.com/c/chromium/src/+/738353 we still wanted to expose loading related entries immediately. I think that kind of reduces the benefit of doing this, but I don't think there's any problem with exposing the rest later (when "idle"). Are you unassigning yourself from this bug?

Ah, right. Not unassigning myself for the moment.

We should maybe update the spec to indicate that loading entries must be exposed immediately? Maybe we need the ability to specify what task queue posting each entry goes onto?

But per call last night we want to move towards a unified processing model. I guess we can have a parameter that tells us whether the entryType is related to loading or not...

I think we need to separate delivery to PO and delivery to the timeline. PO delivery should be async while buffered entries could potentially be delivered synchronously. In order to reconcile the difference (and avoid people abusing the timeline to get entries earlier), we talked about adding a "takeRecords" option to PO. What's the status on that?

takeRecords is already spec'd and ships in Chrome.