- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 30 Oct 2013 15:44:27 -0700
- To: Jatinder Mann <jmann@microsoft.com>
- Cc: Ilya Grigorik <igrigorik@google.com>, Chase Douglas <chase@newrelic.com>, public-web-perf <public-web-perf@w3.org>
On Wed, Oct 30, 2013 at 3:39 PM, Jatinder Mann <jmann@microsoft.com> wrote: > On Oct 30, 2013 2:17 PM, Jonas Sicking wrote: >> I would in fact encourage a good implementation to work hard to submit the beacon. Otherwise websites >> will be more reluctant to depend on it. >> >> Consider for example the case of a search engine that uses a beacon to signal that a link was clicked. If that >> is what enables the search engine to charge an advertiser, they are going to be reluctant to use a feature >> that results in even a couple of percent dropoff in profit. > > Since we don't return success or failure, developers will have a higher expectation that data won't be lost. Though, I'm not sure if the spec should recommend that the user agent persist the data in the event that the browser session is ended. This feels like implementation details that we may want to leave to user agents. Agreed. As long as the spec doesn't forbid it I'm happy. > Also, should the spec recommend an expected time frame in which the data will be sent or just leave it as "best effort to send as soon as possible? What about a timeout? Should we specify that if the data isn't sent by X seconds it'll never be sent? Personally, I'd prefer not giving time frames and just leaving it at best effort. I don't have much of an opinion here. Best effort seems fine with me. Ilya seemed to feel stronger. A timeout argument would be easy to add, though if we do I'd prefer to define that the message is dropped if the timeout is reached, rather than to force the UA to send when the timeout is reached. / Jonas
Received on Wednesday, 30 October 2013 22:45:29 UTC