New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review request for Server-Timing #188
Comments
It would perhaps be useful to see an explainer document here, to answer questions such as why a new specification is needed here rather than reusing existing mechanisms. (My guess at the answer to that particular question is so that timing information for all the resources that are used by the document, no matter what type of resources they are, can be included easily in the timeline.) |
Would also like to see an explainer; we recently put together a dummy outline that could help in drafting yours Would also be good to see discussion of security and privacy considerations in the draft spec. In terms of the design, a few questions:
// Example 2
// serverTiming entries can live on 'navigation' and 'resource' entries
['navigation', 'resource'].forEach((entryType) => {
let entries = performance.getEntriesByType(entryType);
for(let { name: url, serverTiming } of entries) {
// iterate over the serverTiming array; only the slow ones
for(let { name, duration, description } of serverTiming.filter(t => { t.duration > 200 }) {
console.info('Slow server-timing entry =',
JSON.stringify({url, entryType, name, duration, description}, null, 2))
}
} |
The header format that we've chosen for Server Timing is similar to Regarding "specific numeric conversion steps", is there any prior art you can link me to? cc @slightlyoff |
A few notes on the header ABNF:
See also the checklist for new header fields. |
I dug into
I see what you mean, this happened because of a recent change.
I could have this wrong, but I think both are just ascii, which is what we want. for |
A few thoughts from me informed by recent TAG call:
|
@cvazac and @yoavweiss are either (or both) of you available to join a TAG call to discuss this further? We meet at 8am PDT (15:00 UTC) on Sept 12 or 19 would be ideal. |
Discussed on TAG call 5 Sept 2017, particularly questions around the choice not to use JSON. We had a quick look at @reschke's internet draft A JSON Encoding for HTTP Header Field Values. We also had a quick look at its data tracker page... What is the status/momentum of this? Is it implemented anywhere? @mnot, any additional context/input? |
I can join if needed on September 12th.
Implemented with intent to ship in Blink. Intent to implement in WebKit. |
I will join on 9/12. Can someone please send me the details for the call? cc @hadleybeeman |
Great that you both can make it, we'll be using WebRTC via Jitsi: https://meet.jit.si/w3ctag |
Hey all, lots of great discussions here! Meta ask and observation: if there is high-level design feedback you think is worth iterating on, please file issues against the spec repo and let's iterate there, where it's visible to other WG members. We shouldn't (re)design features in this forum. |
@cvazac and @yoavweiss FYI: agenda for tomorrow's call: https://github.com/w3ctag/meetings/blob/gh-pages/2017/telcons/09-12-agenda.md |
Strawman proposal:
Obviously I can't predict all the different types, but the point is that tooling is going to want to visualise these in different ways, for instance:
It seems not hard to build support for this kind of extensibility into the syntax, so as to avoid this:
One might imagine the above is "fine" on the basis that it's not interfering with the intended use of the header, but if the tools for which this header is designed start to look for and depend on this syntax, then it would be very hard to introduce a I'm not a big fan of adding an explicit |
Started w3c/server-timing#32 to discuss feedback from this review and from yesterday's meeting. |
Posted w3c/server-timing#32 (comment) to respond to the proposed changes. Everything looks great. |
Hello TAG!
I'm requesting a TAG review of:
https://github.com/cvazac/server-timing/blob/gh-pages/explainer.md
Further details (optional):
We'd prefer the TAG provide feedback as (please select one):
The text was updated successfully, but these errors were encountered: