On Fri, Nov 7, 2014 at 3:07 PM, Steve Souders <[email protected]> wrote:
> Fastly is interested in this. We would use it to convey backend times (eg, > time to origin, time from cache, etc) to the client. On the client we or > our customers would then combine these backend times with Nav and Resource > times into a single beacon. > Nice. > I can see the desire to convey other info that is not timing like which > data center was used, whether it was a cache hit, etc. So having a way to > pass on non-timing params would be helpful. (Is this addressed in User > Timing? Seems like there would be a similar need.) > <probably a terrible idea> You could encode this data in same key-value pairs.. e.g. c=1, dc=23 --> cache hit = 1 (true); datacenter = 23, where 23 is something meaningful to you. The server controls the names and values, what data it emits, and to whom... so it's a fairly flexible scheme. ig > > On Nov 7, 2014, at 2:00 PM, Ilya Grigorik <[email protected]> wrote: > > https://gist.github.com/igrigorik/97dfe5ea9b4a85162e25 > > We had a brief discussion around this at TPAC, but in the context of > extending User Timing. However, having thought about it some more, I'm > thinking this could/should be an extension for Nav and Resource Timing > interfaces... perhaps even a standalone spec? > > That said, I'm getting ahead of myself... Curious to hear everyone's > thoughts? Is it worth pursuing further? Am I overlooking any major problems > or gotchas? > > ig > >
