On Mon, Nov 10, 2014 at 1:25 PM, Tobin Titus <[email protected]> wrote:
> I’ve been thinking about this since I took on the task of integrating > server-side information into timing spec per our TPAC discussion. > > > > One concern is that it has the potential to add significant weight to the > headers. I’m not necessarily opposed because the actual document is allowed > to add as much weight as it wants as well. And further, I would expect that > some of this information might not be sent unless the developer had opened > up dev tools. > Right, I would expect the general case to be very light - you probably don't want to expose sensitive data (e.g. database time, etc) to every visitor. However, if some auth / debug cookie is present, you could emit more detailed data. As long as we keep the data model simple - i.e. flat, with no nesting, etc - I think we're in good shape. > However, I would suspect that analytics packages might be picking this > data up, and then beaconing it back. It seems strange to send data to the > client just to send it back to the server again. But again, those are > choices left up to the developer. > Not entirely, since you may not be sending this data to the same server :) > While working on the user timing spec this past week, I too was heading > toward a per-resource header that would better fit in resource timing. So, > in general, I’m not opposed to writing this into its own spec instead of > integrating it into user timing. Just let me know if you’d like me to > continue working or if you’d like to take this. > Yep, let's discuss on the conf call tomorrow. On Mon, Nov 10, 2014 at 1:51 PM, Aaron Heady (BING AVAILABILITY) < [email protected]> wrote: > Concur with: I would prefer if server timing values could be > alphanumerics, rather than having to encode datacenters as numbers as > discussed earlier. > Yeah, I think we should seriously consider the annotations proposal, I think it solves this particular problem in a much nicer way. ig
