Re: [HighResTime] Web Worker support

I think we'd just add a new field named creationTime to the SharedWorker
interface. It'd be defined as the difference between the shared worker's
initial construction time and navigationStart.

I can put something in the spec if this sounds ok.

James


On Wed, Oct 2, 2013 at 11:31 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  This sounds like a good idea. How do you propose we expose this data in
> the parent page? Especially interested in the scenario where the parent
> page is communicating with multiple shared workers.****
>
> ** **
>
> Jatinder****
>
> ** **
>
> *From:* James Simonsen [mailto:simonjam@google.com]
> *Sent:* Monday, September 16, 2013 4:50 PM
> *To:* James Robinson
> *Cc:* Jatinder Mann; public-web-perf@w3.org
>
> *Subject:* Re: [HighResTime] Web Worker support****
>
> ** **
>
> That works for me.****
>
> ** **
>
> We should probably call out that it could be negative if the shared worker
> was started before this instance of the page loaded.****
>
> ** **
>
> James****
>
> ** **
>
> On Mon, Sep 16, 2013 at 4:45 PM, James Robinson <jamesr@google.com> wrote:
> ****
>
>  If the use case is to correlate window.performance.now() times within a
> worker to that in a parent page, why not expose the worker creation time in
> the parent page's epoch to the parent?  This would be the difference in
> epochs between the parent and worker page's window.performance.now() times.
>  The parent could postMessage() this to a child or to other pages if it
> liked.****
>
> ** **
>
> - James****
>
> ** **
>
> On Mon, Sep 16, 2013 at 4:34 PM, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
>  To avoid the privacy issue, seems like we may need to go with a new
> epoch. However, wouldn’t using a new epoch still suffer from the issue of
> the clock being adjusted while the application is running?****
>
>  ****
>
> I don’t have any concerns with using January 01 2013 as a new epoch
> (better than the suggestion to use someone’s birthday ;) ****
>
>  ****
>
> *From:* James Simonsen [mailto:simonjam@google.com]
> *Sent:* Monday, September 16, 2013 12:02 PM
> *To:* public-web-perf@w3.org****
>
>
> *Subject:* Re: [HighResTime] Web Worker support****
>
>  ****
>
> So is the best solution to just pick a new epoch that's relatively recent?
> Like 1/1/2013?****
>
>  ****
>
> James****
>
>  ****
>
> On Wed, Sep 11, 2013 at 6:37 PM, James Robinson <jamesr@google.com> wrote:
> ****
>
>  On Wed, Sep 11, 2013 at 11:45 AM, Jatinder Mann <jmann@microsoft.com>
> wrote:****
>
>   ****
>
> Adding originTime to the performance.now(), gives you a time value that is
> comparable in either context. This assumes that we have enough bits in a
> double to describe time since Jan 01 1970 in milliseconds in microsecond
> resolution.****
>
>   ****
>
> There have been a bit more than 2^40s microseconds since the unix epoch.
>  A double has 53 bits of mantissa so I think we're safe for a while.  A
> problem here is that the unix epoch is not at a fixed point relative to the
> monotonic clock.  Remember that the monotonic clock is monotonic is
> monotonic in terms of itself.  The computer that the application is running
> on may have its clock adjusted forwards or backwards while the app is
> running and in practice this happens surprisingly frequently.  This does
> not impact the monotonic clock, but it does change the delta to the unix
> epoch.  That's why window.performance.now() *has* to use a timebase
> different from the unix epoch.  What do you propose we do in this case?***
> *
>
>  ****
>
>   ****
>
> Alternatively, we can define the origin for originTime to be the launch of
> the browser.****
>
>  ****
>
>   ****
>
> Defining the time to be relative to launch of browser allows identifying
> that browser session across multiple sites and visits by comparing the time
> to Date.now().  That'd be a really bad idea.****
>
>  ****
>
> - James ****
>
>   ****
>
>  ** **
>
>  ** **
>