See also: IRC log
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
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
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?
<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
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
[End of minutes]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[End of scribe.perl diagnostic output]