Define performance.transferable + TransferableDOMHighResTimeStamp interface

[igrigorik]

Preview: https://rawgit.com/w3c/hr-time/transferable/index.html

Attempt to flush out a replacement for performance.translateTime, as discussed in #22 (comment):

• To transfer a DOMHighResTimeStamp between globals developer needs to first "wrap it" via performance.transferable(), which returns a TransferableDOMHighResTimeStamp object.
• To resolve the transferred timestamp from a different time origin, the developer calls time() on the received TransferableDOMHighResTimeStamp object. Calling the method invokes a calculation which maps the wrapped DOMHighResTimeStamp and it's origin into current global's time origin and returns a new DOMHighResTimeStamp.

Take a look at the updated example in the intro section for a hands-on example. Suggestions on names, wording, etc., welcome! I believe this would resolve #21, #22, #23.

With respect to use cases and motivation (i.e. why is Date() not sufficient?): same reasons why DOMHighResTimeStamp was created in the first place; if we assume a world where workers are often used to perform and offload computation / network activity / etc, it's important that we provide and enable access to monotonic + high-resolution time.

/cc @sicking @DigiTec @annevk @bzbarsky @natduca

[toddreifsteck]

Had a talk with @DigiTec about this. This doesn't cover the performance.getEntries().toJson() being transferred across context boundaries. That seems like an important sub-scenario. What do you think?

[igrigorik]

Hmm, I'm not sure we can solve the toJson() case... as that, once again, would require embedding some global timestamp in the JSON itself, which runs into same privacy issues as we discussed in #22.

That said, the use case itself is an important one: you want to exchange PerformanceEntry between different contexts and have the ability to resolve their timestamps in different origins.

The first idea that comes to mind is to extend performance.transferable() to accept PerformanceEntry objects, which would then similarly be wrapped can be resolved in a different context?

(Arguably we could automate all this... E.g. each PerformanceEntry object could maintain a reference to the time time-origin where it was created and automatically resolve the timestamps by checking the current vs created time-origin and doing the translation? This does add overhead.. but it's completely transparent to the user, which is a pretty big plus. Crazytalk?)

[toddreifsteck]

Are we 100% sure that the privacy issue in #22 can't be mitigated?

[igrigorik]

I don't see how, but if you have ideas or suggestions I'm all ears..

[toddreifsteck]

#26 contains a focus on solving this issue and discussing various privacy spins....

[igrigorik]

Closing, based on discussions in #22.