LGTM. One thing that's going to be interesting is to see how developer tools visualise this, since that's usually a timeline, and as you say this isn't relative to the client's view of time.
I suspect they might just show it in the server-side portion of things, and clarify (how) that it's showing a proportion of the server time, not an implicit ordering. That may be a big ask, though. Tell me if you need help with specifying the header ABNF, etc. Cheers, > On 20 Nov 2014, at 2:08 am, Ilya Grigorik <[email protected]> wrote: > > A (really) rough draft: > https://cdn.rawgit.com/igrigorik/f940a4705a83f6ec2225/raw/0533e5809606abe2ee9c514a95ca6e7da02975be/server-timing.html > > Does the general shape and functionality feel about right? I've tried to > capture the use cases we've discussed on this thread and map those to > existing HTTP syntax for parameters and modifiers. > > - I've omitted timestamps, because we can't reasonably map those into the > client's timeline. > - Metrics can have an optional value, description, or both... i.e. you can > report a [name], [name, duration], [name, duration, description], [name, > description]. I think that covers all the necessary cases? > > For now, I've also intentionally omitted the plumbing to expose the > metrics... I think we have two options: > 1) Extend NavTiming / ResourceTiming entries to contain a "serverMetrics" (or > some such), which would be an array of above server metrics. > 2) Expose server metrics as own type alongside other existing metrics. > > Thoughts, feedback? > > ig > > On Wed, Nov 12, 2014 at 8:18 PM, Ilya Grigorik <[email protected]> wrote: > > On Wed, Nov 12, 2014 at 9:40 AM, Eli Perelman <[email protected]> wrote: > I agree with this, and so I believe that any timestamps sent through this > proposal should probably not be displayed in a timeline. If you want to do > calculations between any of the existing timings and the "server" timings, it > should be manual. > > This breaks one of the primary use cases for this proposal - i.e. to surface > additional request timing data in developer tools. That's a -1 for me. > > So it appears that Server Timing may be a bit of a misnomer to get at what > I'm trying to achieve here, which is to get meaningful timestamps generated > externally from the client to the client. If we were only handling the use > case of a server communicating information about itself to the client then I > could understand, but I believe this API could be more powerful and > extensible if we don't limit it with the server-to-browser standard model. I > guess what I am getting at is let's make this less about the server, and more > about external timing which would include the server. External Timing, > Supplemental Timing, I digress... > > Just because it's not a remote server doesn't make this any easier. For > example, request gets routed to ServiceWorker, which then goes on to do some > arbitrary amount of work (check cache, update cache, <whatever>), and then > returns a response... Any timestamp that it generates is not directly > relatable to the timeline of the document that initiated the request -- the > only thing we can communicate safely is the duration of one or more events. > > I'm still of the mind that we should stay away from timestamps... That said, > if you *really* wanted them, and if we add some form of annotations, you > could communicate your timestamps as annotation and implement your app logic > to process them accordingly. > > ig > > -- Mark Nottingham [email protected] https://www.mnot.net/
