Server Timing feedback from TAG

igrigorik: let's start with Server Timing

cvazac: We attempted to ship, then TAG review happened
... they brought up concerns about future extensibility, units and other use cases to enable full fledged server side tracing framework
... so made a proposal to make all parameters other than "name" named, so we can add more parameters in the future

<igrigorik> proposal: Server-Timing: name=foo; start=100; duration=0

<igrigorik> doh, sorry.. Server-Timing: foo; start=100; duration=0

cvazac: we want to use existing art to parse these headers. This looks very much like the Link header parsing, so we can reuse most of that code

igrigorik: so we agreed on not naming the "name", right?

cvazac: all for skipping "name="

igrigorik: it gives us an option to extend the format in the future, which is a good thing. How would it impact consumers, e.g. Chrome dev tools?

cvazac: we can change that. They are not very worried.

yoav: We previously talked to the devtools and talked about supporting both syntaxes for a while

igrigorik: then let's do the spec and impl changes and get Paul Irish to review

User Timing L2 issues

igrigorik: so, user timing
... we added a capability to reference named marks, never updated to cover NT2, and we throw exceptions in various non-consistent cases
... maybe we can just drop this whole thing?
... a bunch of shipping implementations, not necessarily consistent. Can we drop it? If we do, what are we missing?

todd: are we sure that we don't need that?
... we need telemetry on usage before discussing dropping it

igrigorik: what are the alternatives? It only works with NT1?

todd: The implementations work with part of NT2, we need to fix the spec

igrigorik: for NT3 when we'd support redirects, it'll get very messy

todd: We really need real usage metrics before discussing dropping it

igrigorik: if it's used in 0.1% what would that give us?

philip: Can we freeze the future to what's currently supported?
... If a used is using a marked name, it limits the strings we can use in the future

yoav: maybe a namespace for future entries?

igrigorik: We have a proposed model for referencing entries directly

nolanlawson: We can pass in the entry directly instead of strings that proxy them

igrigorik: are there 2 components? one is "mark" and the other is NT? How would you pass in NT entries?

todd: strings model is a key-value pair

igrigorik: we should support passing NT entries, not sure how to support that use case

nolanlawson: so we need to support passing in arbitrary timestamps

todd: the name you're passing in is just a pointer.
... so we can pass in timestamp and name as a replacement to the string model if we can get everyone to convert

philip: discussion from TTI definition where you don't know how TTI happened until it's passed
... so there's a use case for creating a user timing entry in the past

igrigorik: a few updates a) current exception behavior - we need to gather metrics and try to kill it

if there's usage - lock in the current strings and freeze it

in L3 we can try to return an entry object from mark and measure, supporting timestamps and events

todd: makes sense and probably a simple addition

igrigorik: nolan, would you guys be interested in driving that work?

nolanlawson: sure

igrigorik: custom perf entries kinda plays in the same space

maybe we need to merge concepts

philip: worthwhile to think about both at the same time

igrigorik: maybe implement user timing using custom entries

nolanlawson: is chrome already exposing custom metrics in dev tools?

philip: experimental implementation in the UI but not in JS

PerfObserver

igrigorik: PerfObserver
... interesting incidents a few weeks ago, large sites shipped PO code and hit problems with the exception behavior

longtasks PO was raising exceptions and it wasn't guarded for

joepack suggested to drop exceptions entirely

todd: example with the problems in being a late implementor

yoav: what's the feature detection story other than exceptions?

igrigorik: maybe calling observe can return the list of things that are observed?

todd: that may add a cost for feature detection

cvazac: There should be a single way to feature detect

igrigorik: so rough consensus to drop the exceptions. Maybe we can add console warnings
... how do we feature detect? Joe did not want an "isSupported" type of API

todd: specific interfaces checked exist on window, but not in PO

igrigorik: we previously talked about `supports` for both PO and TL. Does it make sense to expose several things?

todd: Firefox are rolling back PO because of PO feature detection

igrigorik: so remove exceptions, and create a direct array of supported types that PO supports

plh: should I make a PR to remove the exceptions and the test?

igrigorik: yes, plz!

cvazac: what about the console warning?

igrigorik: maybe add a note saying UA can do that
... is Dale around for time origin discussion?

Triage Dale’s feedback on time origin + unload

<igrigorik> https://github.com/w3c/web-platform-tests/pull/6241#issuecomment-331347123

Dale: this comes down to the wording that defines the time origin

diagram shows 2 potential points for time origin

the 1 implemented is not great

if you measure from an onunload event, implementations use the origin of the previous document

todd: in unload we have 2 time origins
... so the spec is ambiguous regarding what time origin should unload use

Dale: easier to test the implemented behavior than the spec behavior

if the spec is corrected to match current behavior, it's testable

cannot test the negative case, so can't measure you're not measuring using the wrong time origin

todd: so Dale will get in a more complex test and PR to update the spec

Administrative / check-in

igrigorik: Any updates on beacon tests?

todd: no

igrigorik: RequestIdleCallback - any updates?

plh: got it dropped off my list. Will take care of it

igrigorik: preload CR and discussion of a TAG review

xiaoqian: we should send a review request today and wait 2 weeks

yoav: let's coordinate reviews over email

igrigorik: October 9th for next meeting due to Akamai Edge

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/edition/addition/
Succeeded: s/onload/onunload/
Succeeded: s/siusin/xiaoqian/
Present: igrigorik yoav nolanlawson NicJ plh xiaoqian cvazac philip dale Josh todd
Found Scribe: yoav

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit#heading=h.kplnsudwiv74
Got date from IRC log name: 25 Sep 2017
Guessing minutes URL: http://www.w3.org/2017/09/25-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