On Wed, Nov 12, 2014 at 7:10 AM, Eli Perelman <[email protected]> wrote:
> I really like this proposal, but I do find keeping the values as durations > to be somewhat limiting. Just as we have performance marks and measures, I > feel that being able to provide both durations and timestamps to the client > would be useful. > > A specific use case: On Firefox OS, it would be valuable to specify in > this header when the user initiated to open an application. The "home > screen" (acting as the server in this proposal) could specify in the header > that at a certain timestamp, the user tapped on an icon, and the > application (acting as the client) would then be able to make a more > deterministic evaluation for how long it actually took load. Drawback: not > sure of the implications of introducing timestamps or possible negative > values into the timeline of an application, but that is something we could > discuss. > > Thoughts? The problem is that server and client have completely different clocks.. - they're not synchronized, nor can we expect or make them be synchronized - client uses hr-time and its timestamps are with respect to navigationStart We can't meaningfully map server generated timestamps into the timeline, I think we should stick to duration only. ig
