- From: Todd Reifsteck <toddreif@microsoft.com>
- Date: Wed, 10 Jun 2015 05:38:02 +0000
- To: Boris Zbarsky <bzbarsky@mit.edu>, Ilya Grigorik <igrigorik@google.com>, Justin Rogers <justrog@microsoft.com>
- CC: Jonas Sicking <jonas@sicking.cc>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Przemysław Pietrzkiewicz <ppi@google.com>, Travis Leithead <travis.leithead@microsoft.com>
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