RE: More on workerStart

Boris/Ilya/Justin,
Please let me know if I miss anything in the following Summary.

We've defined the following requirements..
* We'd like an easy way to get the workerStart within a context
* We'd like a way to easily convert workerStart to a new timeOriginBasis

Current proposal:
*Add the following to AbstractWorker--
 DOMHighResTimeStamp computeWorkerStart([SameOrigin] optional (Window or WorkerGlobalScope) timeOriginBasis);
* timeOriginBasis is looked up from the incumbent settings object if not specified
* workerStart becomes a call to computeWorkerStart() and must become unsettable or it is vulnerable to confused timeOriginBasis by developers


Also.. WebIDL thought occurred in the midst of the conversation (Who can take this to WebIDL group? Travis/Justin/Boris):
Consider making SameOrigin the default and adding AllowCrossOrigin and updating various WebIDL.
 
-Todd

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 
Sent: Tuesday, June 9, 2015 6:15 PM
To: Ilya Grigorik
Cc: Justin Rogers; Jonas Sicking; public-web-perf@w3.org; Przemysław Pietrzkiewicz
Subject: Re: More on workerStart

On 6/9/15 4:50 PM, Ilya Grigorik wrote:
> Yes, but this requires a roundtrip

You mean through wall-clock times?  Then yes.  Hence "somewhat reason".

> Would it make sense to expand the scope of this discussion to a method 
> that can accept both worker and window objects to compute their 
> respective startTime's?

It might make sense to do that, yes.

-Boris

Received on Wednesday, 10 June 2015 05:38:32 UTC