- From: Andrew Betts <notifications@github.com>
- Date: Tue, 12 Sep 2017 10:08:24 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/188/328919618@github.com>
Strawman proposal: ``` Server-Timing: db-start=100;type=moment, db-duration=50;type=duration, peak-memory=4525345;type=bytes, data-center=LHR;type=enum, cache-status=HIT;type=enum, user-id=3457853;type=str ``` 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: * Durations as horizontal bars * Moments as vertical lines / dots * Bytes scaled to an appropriate human-readable unit (tool might also conceivably compare the value with values for the same metric for previous requests) * ENUMs as tag-style labels, perhaps with automatic colour coding * Freefrom strings as just basic tabulated data It seems not hard to build support for this kind of extensibility into the syntax, so as to avoid this: ``` Server-Timing: data=;<URL-ENCODED-JSON> ``` 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 `type` attribute later on. I'm not a big fan of adding an explicit `description` attribute key, because I do ultimately think that a string value should not have to live in a meta property just because you have reserved the main value property for a millisecond duration. However, a meta property seems like a reasonable solution (and an alternative to a unit) to switch the processing model that should apply to the main value. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/188#issuecomment-328919618
Received on Tuesday, 12 September 2017 17:08:45 UTC