- From: Arvind Jain <arvind@google.com>
- Date: Mon, 18 Aug 2014 00:05:09 -0700
- To: Sigbjorn Finne <sof@opera.com>
- Cc: public-web-perf <public-web-perf@w3.org>, Adam Barth <abarth@chromium.org>, David Benjamin <davidben@chromium.org>
Got it. Given how we wrote it, it would be before the Fetch is initiated. So it would be before the request is sent to the network stack. On Sun, Aug 17, 2014 at 11:39 PM, Sigbjorn Finne <sof@opera.com> wrote: > Den 18.08.2014 08:14, skreiv Arvind Jain: > >> #11 is left to the user agent. In the usual case, it is hopefully soon >> after step 10, but it can de delayed. Is it what you are asking? >> > > It's in that area. So a UA is allowed to sample the time ("current time") at > any point after it decides to go ahead with the Beacon request that > sendBeacon() initiated, and there being no assumption that any/all > client-side&measurable delays have been performed when it does so? > > --sigbjorn > > >> On Sun, Aug 17, 2014 at 10:12 PM, Sigbjorn Finne <sof@opera.com> wrote: >>> >>> Den 18.08.2014 04:03, skreiv Arvind Jain: >>> >>>> requestTime should be set to the time immediately after sendBeacon() >>>> is called. So it should be before the actual Fetch is performed. The >>>> actual Fetch may be performed quite a bit later (e.g. if the user >>>> agent decides to delay the transmission). >>>> >>> >>> That makes sense, what about the other end of the interval that the age >>> value captures, when is it assumed sampled, i.e., when is step 11 >>> performed? >>> (That was what I was referring to, sorry about confusing the spec >>> naming.) >>> >>> --sigbjorn
Received on Monday, 18 August 2014 07:05:37 UTC