- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Aug 2015 13:36:14 +0000
- To: public-webtiming@w3.org
Hmmm, this probably amounts to the same result in the end and thus it may be just a matter of taste, but I find it much more intuitive to ask the timing provider for an evaluation of the current time than to ask it for an evaluation of when a past event occurred (or perhaps more accurately for an evaluation of when a past event should be seen as having occurred to be able to compute the proper elapsed number of milliseconds). I would rather keep `ts_init` constant in your example: it is the timing provider's evaluation of when the initial vector was set. When that evaluation was made, it was as accurate as possible, even though clocks may have drifted since then, so I don't see why it should change over time. And I would thus ask the timing provider for an evaluation of `ts_now`. That's what the `now()` method does. This way, it exposes the software clock that the timing provider needs to maintain and keep in sync with the server clock. The user agent would then synchronize its internal software clock with this clock using any "usual" clock synchronization mechanism. If the timing provider fails to implement a monotonic clock, the user agent could also use that synchronization opportunity to fix that (instead of throwing an `OperationError` as currently defined in the spec). Said differently, I would let the user agent handle the mapping between the clock exposed by the timing provider and the `performance.now()` timeline. Actually, the time origin used by the timing provider does not even really matter (so values it reports do not necessarily have to be on the timeline of the `performance.now()` clock) since we're really just interested in computing differences between two timestamps. Do you see any notable advantages or drawbacks with either approach? -- GitHub Notif of comment by tidoust See https://github.com/webtiming/timingobject/issues/16#issuecomment-134202853
Received on Monday, 24 August 2015 13:36:15 UTC