W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2013

Re: [Beacon] spec feedback + few suggestions

From: Chase Douglas <chase@newrelic.com>
Date: Thu, 7 Nov 2013 15:31:24 -0800
Message-ID: <CAKNWE6HGhJLmBqkakojpJk4KFwCa6_LCFMHj60oFM4UaPZZqzw@mail.gmail.com>
To: Jatinder Mann <jmann@microsoft.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Ilya Grigorik <igrigorik@google.com>, "Austin, Daniel" <daaustin@paypal.com>, public-web-perf <public-web-perf@w3.org>
I'm not sure I can think of a use case for the browser context, but
sometimes there are scenarios where you want to send data now, but there's
no point if the data is delayed for 5 minutes from now. It will have been
past the point of usefulness. So I can imagine the purpose of such a
mechanism, but I can't think of a good use case for it.

On Thu, Nov 7, 2013 at 3:27 PM, Jatinder Mann <jmann@microsoft.com> wrote:

> On Thur, Nov 7, 2013 at 11:34 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > Actually, if we want to add a timeout argument in the future (after
> which the beacon is dropped on the floor)
> > that would also be a reason to make the last argument a dictionary for
> now.
> What's the use case with timeouts? Will I wait for the timeout period,
> somehow check if the beacon was not received by the server, and try again?
> If that's the use case, then we may have given developers a reason to
> continue to delay the onload by checking if the beacon was not sent and
> retrying. If our goal is to design a fire and forget way to send data, this
> may cause problems.
Received on Thursday, 7 November 2013 23:31:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC