Intent to implement: Beacon

[Sigbjørn Finne]

*Contact emails:*

sigb...@opera.com

*Spec:*

https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html

*Summary:*

Navigator object API for asynchronously transferring data during
document unload.

*Motivation:*

Some web apps need to sync/flush state during document unload. The
existing mechanisms used to accomplish that (sync XHRs, image loads) in
document unload handlers aren't reliable and do slow down page navigation.
The Beacon API (navigator.sendBeacon()) tries to address that by
providing a method for the UA to asynchronously transmit such data,
without blocking page navigation.

*Compatibility Risk:*

Low; adding this new method on Navigator shouldn't break existing
content, and if the method has to be retired for one reason or another,
the above fallbacks and others can (again) be used by web content
relying on such data flushing.

As far as compatibility with other browsers goes, Gecko has
implemented Beacon,

https://bugzilla.mozilla.org/show_bug.cgi?id=936340

*Ongoing technical constraints:*

None; a smaller and contained platform addition.

*Will this feature be supported on all five Blink platforms (Windows, Mac,
Linux, Chrome OS and Android)?*

Yes.

*Link to entry on the feature dashboard*

N/A - probably worth adding if this intent is approved.

*Requesting approval to ship?*

Not at this time.

*Links:*

Bug: https://code.google.com/p/chromium/issues/detail?id=360603
CL (in preparation): https://codereview.chromium.org/232053005/

[Eric Seidel]

How does this relate to XHR? Is this a higher-level idea or a
lower-level one? If it's higher-level, presumably we might later
expose a "xhr.ignoresResponse = true" flag?

In any case, this explains <a ping> which fits with the goal of a
layered platform.

[Jeffrey Yasskin]

I have no lgtm to offer, just 2¢:

With Service Workers
(https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md),
a Beacon is similar to sending a message to the SW, and having the SW
do the network request. The SW has no guarantee that it'll stay alive
long enough to finish the request, but the Beacon standard also uses
SHOULD to describe the UA's behavior.

On Thu, Apr 10, 2014 at 8:54 AM, Sigbjørn Finne <s...@opera.com> wrote:

[Ilya Grigorik]

On Thu, Apr 10, 2014 at 10:14 AM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

With Service Workers
(https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md),
a Beacon is similar to sending a message to the SW, and having the SW
do the network request. The SW has no guarantee that it'll stay alive
long enough to finish the request, but the Beacon standard also uses
SHOULD to describe the UA's behavior.

True, but I don't think we want to couple these / require ServiceWorker to get Beacon-like behavior. 

ig

[Sigbjørn Finne]

On Thu, Apr 10, 2014 at 6:47 PM, Eric Seidel <ese...@chromium.org> wrote:

How does this relate to XHR?  Is this a higher-level idea or a
lower-level one?  If it's higher-level, presumably we might later
expose a "xhr.ignoresResponse = true" flag?

Achieving same with sync XHR is what's done today quite often, but there

are downsides (as outlined below + see the spec intro.) Overloading XHR with

a "fire-and-forget" semantics, in the form of a send(), rather than adding even

more state to XHR. is an alternative, should such a proposal spring into being.

You could also say that this is related to wanting the ability to send datagrams;

i.e., there's nothing novel in the base functionality provided, but Beacon tries to

solve a smaller problem we're faced with wrt speed of page navigation. And

others are behind its implementation, so having an on-par platform offering is

also a consideration.

 

In any case, this explains <a ping> which fits with the goal of a
layered platform.

Quite; see CL, although with different primary end goals.

--sigbjorn

[Adam Barth]

To me, this part is the strongest argument in favor of this feature.

Adam

[Mounir Lamouri]

It might be a naive question but why not simply implement a
xhr.ignoreResponse property instead of sendBeacon()?

-- Mounir

[Sigbjorn Finne]

Apart from this property not being spec'ed, I can see some problems
with adding more state to the XMLHttpRequest object.

It's already a non-trivial exercise to get the spec precise and
achieve compatibility across browsers in the face of state changes
to an XHR instance.

But, as stated previously, if the XHR spec evolves functionality like
this, then it would be something to consider for an intent-to-implement.

--sigbjorn

[Anne van Kesteren]

On Wed, Apr 16, 2014 at 7:23 PM, Sigbjorn Finne <s...@opera.com> wrote:
> It's already a non-trivial exercise to get the spec precise and
> achieve compatibility across browsers in the face of state changes
> to an XHR instance.

I don't think it would be such a big issue for XMLHttpRequest. The
main problem with this feature is not cancelling the fetch once the
Document disappears. I don't think any specification defines that in
detail.

Beacon meanwhile has a bunch of issues:
http://lists.w3.org/Archives/Public/public-web-perf/2014Feb/0048.html
(most of them still unaddressed, just asked for an update).


--
http://annevankesteren.nl/

[Mounir Lamouri]

On Thu, 17 Apr 2014, at 5:15, Anne van Kesteren wrote:
> On Wed, Apr 16, 2014 at 7:23 PM, Sigbjorn Finne <s...@opera.com> wrote:
> > It's already a non-trivial exercise to get the spec precise and
> > achieve compatibility across browsers in the face of state changes
> > to an XHR instance.
>
> I don't think it would be such a big issue for XMLHttpRequest. The
> main problem with this feature is not cancelling the fetch once the
> Document disappears. I don't think any specification defines that in
> detail.

Anne, if adding a property to XHR to tell the UA to ignore the response,
can't the XHR spec recommend implementations to finish requests with
that flag in the background when the document gets unloaded?

-- Mounir

[Anne van Kesteren]

On Wed, Apr 16, 2014 at 9:05 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> Anne, if adding a property to XHR to tell the UA to ignore the response,
> can't the XHR spec recommend implementations to finish requests with
> that flag in the background when the document gets unloaded?

Yeah it could. I think what we need is for a document to keep track of
a list of fetches. Then when a document goes away the fetches can be
terminated. This type of beacon fetch would simply not be added to the
list. Not sure where we should define that list yet.


--
http://annevankesteren.nl/

[Darin Fisher]

In addition to the other suggestions in this thread, have you looked at programmatically creating an anchor element with a ping attribute and then synthesizing a click event on it? Does that work equally well?

Second question: Our implementation of <a ping> does nothing to ensure that the network request completes if the browser is meanwhile shutting down. Should it? Should Beacon API?

-Darin

[Boris Zbarsky]

On 4/16/14 4:19 PM, Anne van Kesteren wrote:
> Yeah it could. I think what we need is for a document to keep track of
> a list of fetches. Then when a document goes away the fetches can be
> terminated. This type of beacon fetch would simply not be added to the
> list. Not sure where we should define that list yet.

Note that you'll need to neuter various parts of the XHR processing
model too (e.g. anything involving events or callbacks).

Maybe it's worth introducing that complexity to XHR. It's hard to tell.
Note that all of this was discussed before the current Beacon setup
was decided on, so people might want to go read that discussion as a start.

-Boris

[Sigbjørn Finne]

On Wed, Apr 16, 2014 at 10:40 PM, Darin Fisher <da...@chromium.org> wrote:

In addition to the other suggestions in this thread, have you looked at programmatically creating an anchor element with a ping attribute and then synthesizing a click event on it? Does that work equally well?

You could do something along those lines. But I see at least two problems with that -- the page would have to go to extra lengths to encode the different kinds of data that sendBeacon() supports in that ping URL (e.g., FormData, ArrayBufferView, arbitrary string.) And scripts would have to create <a ping> elements and dispatch events during unload (where sendBeacon()'s main use case lies) to achieve this. Doesn't sound entirely ideal.

 

Second question: Our implementation of <a ping> does nothing to ensure that the network request completes if the browser is meanwhile shutting down. Should it? Should Beacon API?

Good question. The Beacon spec says the UA should make a "best effort" to send the beacon. There are no guarantees of delivery. The HTML spec makes no mention of this issue, afaict.

--sigbjorn

[Anne van Kesteren]

I wasn't trying to advocate one way or another. I wanted to note that
the current setup does not adequately describe the way fetching works,
but arguably that's not the fault of the beacon API in particular (it
not using hooks appropriately is), but rather of fetching in general
not being defined enough. Although Ian Hickson raising that issue with
me rather than the Web Performance WG is somewhat weird of course...


--
http://annevankesteren.nl/

[Darin Fisher]

On Wed, Apr 16, 2014 at 2:01 PM, Sigbjørn Finne <s...@opera.com> wrote:

On Wed, Apr 16, 2014 at 10:40 PM, Darin Fisher <da...@chromium.org> wrote:

In addition to the other suggestions in this thread, have you looked at programmatically creating an anchor element with a ping attribute and then synthesizing a click event on it? Does that work equally well?

You could do something along those lines. But I see at least two problems with that -- the page would have to go to extra lengths to encode the different kinds of data that sendBeacon() supports in that ping URL (e.g., FormData, ArrayBufferView, arbitrary string.) And scripts would have to create <a ping> elements and dispatch events during unload (where sendBeacon()'s main use case lies) to achieve this. Doesn't sound entirely ideal.

I agree that Beacon API is easier to use. I think my question gets to the motivation for Beacon API.

Is it that web developers do not understand that they can use <a ping> in this way that they do not? Or, do we know that they do not? You didn't mention <a ping> in the motivation section.

Also, Blink allows IMG loads that start during an unload handler to proceed uninterrupted past unload. This is for compatibility with IE6 (and presumably later versions as well).

I'm curious why IMG loads started during unload are not sufficient to address the use case of Beacon API. Again, Beacon API is a much nicer API, but the core functionality is already present in the platform, right?

Is Beacon API purely syntactic sugar over existing functionality? Can it be polyfilled on top of existing functionality?

 

 

Second question: Our implementation of <a ping> does nothing to ensure that the network request completes if the browser is meanwhile shutting down. Should it? Should Beacon API?

Good question. The Beacon spec says the UA should make a "best effort" to send the beacon. There are no guarantees of delivery. The HTML spec makes no mention of this issue, afaict.

I bet Beacon API, <a ping> and even IMG started during unload will all be less than what web developer want unless we improve the implementation to make a better effort to deliver the pings in the presence of browser shutdown, network errors, etc.

It would be nice if we had more data to understand what web developer really want from a beaconing API and what they aren't getting from the current platform.

-Darin

 

--sigbjorn

[Sigbjorn Finne]

Den 16.04.2014 23:40, skreiv Darin Fisher:
> On Wed, Apr 16, 2014 at 2:01 PM, Sigbjørn Finne <s...@opera.com> wrote:
>
>> On Wed, Apr 16, 2014 at 10:40 PM, Darin Fisher <da...@chromium.org> wrote:
>>
>>> In addition to the other suggestions in this thread, have you looked at
>>> programmatically creating an anchor element with a ping attribute and then
>>> synthesizing a click event on it? Does that work equally well?
>>>
>>>
>> You could do something along those lines. But I see at least two problems
>> with that -- the page would have to go to extra lengths to encode the
>> different kinds of data that sendBeacon() supports in that ping URL (e.g.,
>> FormData, ArrayBufferView, arbitrary string.) And scripts would have to
>> create <a ping> elements and dispatch events during unload (where
>> sendBeacon()'s main use case lies) to achieve this. Doesn't sound entirely
>> ideal.
>>
>
> I agree that Beacon API is easier to use. I think my question gets to the
> motivation for Beacon API.
>
> Is it that web developers do not understand that they can use <a ping> in
> this way that they do not? Or, do we know that they do not? You didn't
> mention <a ping> in the motivation section.
>

People involved in the Web Performance WG would know better, but indications
are that the preference among web developers is to use sync XHRs in unload
handlers to flush their data, and not any of the alternatives mentioned
here, including <a ping>. cf.,

http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0442.html

--sigbjorn

[Darin Fisher]

Hmm, reading that doesn't suggest that Beacon API will fare better than existing methods. Hmm...

-Darin

 

--sigbjorn

[Ilya Grigorik]

On Wed, Apr 16, 2014 at 2:40 PM, Darin Fisher <da...@chromium.org> wrote:

I agree that Beacon API is easier to use. I think my question gets to the motivation for Beacon API.

Is it that web developers do not understand that they can use <a ping> in this way that they do not? Or, do we know that they do not? You didn't mention <a ping> in the motivation section.

<a ping> does not allow me to POST data, which is one of the primary use cases for a lot of analytics reporting. 

 

Is Beacon API purely syntactic sugar over existing functionality? Can it be polyfilled on top of existing functionality?

I don't believe so. There was a lengthy discussion on this topic on public-web-perf and between all the various hacks (images, sync xhrs, etc), none could fulfill all of the criteria. Further, from experience we know that even with current "state of art" methods, there is significant beacon loss (anecdotally ~30% from various sites). The goal of Beacon is to provide a simple API (that actually works) and much better delivery rate.

ig 

[Darin Fisher]

On Wed, Apr 16, 2014 at 4:03 PM, Ilya Grigorik <igri...@google.com> wrote:

On Wed, Apr 16, 2014 at 2:40 PM, Darin Fisher <da...@chromium.org> wrote:

I agree that Beacon API is easier to use. I think my question gets to the motivation for Beacon API.

Is it that web developers do not understand that they can use <a ping> in this way that they do not? Or, do we know that they do not? You didn't mention <a ping> in the motivation section.

<a ping> does not allow me to POST data, which is one of the primary use cases for a lot of analytics reporting. 

Right, you need to encode it in the URL. Are you saying the ability to construct a POST request is the only feature missing from the existing platform? (IMG and <a ping> requires you to encode the information in the URL.)

 

 

Is Beacon API purely syntactic sugar over existing functionality? Can it be polyfilled on top of existing functionality?

I don't believe so. There was a lengthy discussion on this topic on public-web-perf and between all the various hacks (images, sync xhrs, etc), none could fulfill all of the criteria. Further, from experience we know that even with current "state of art" methods, there is significant beacon loss (anecdotally ~30% from various sites). The goal of Beacon is to provide a simple API (that actually works) and much better delivery rate.

It doesn't sound like Beacon API will do anything to improve beacon loss.

-Darin

[Mounir Lamouri]

Unless UAs delay shutdown in order to get those beacon sent?

-- Mounir

[Ilya Grigorik]

On Wed, Apr 16, 2014 at 4:18 PM, Darin Fisher <da...@chromium.org> wrote:

On Wed, Apr 16, 2014 at 4:03 PM, Ilya Grigorik <igri...@google.com> wrote:

On Wed, Apr 16, 2014 at 2:40 PM, Darin Fisher <da...@chromium.org> wrote:

I agree that Beacon API is easier to use. I think my question gets to the motivation for Beacon API.

Is it that web developers do not understand that they can use <a ping> in this way that they do not? Or, do we know that they do not? You didn't mention <a ping> in the motivation section.

<a ping> does not allow me to POST data, which is one of the primary use cases for a lot of analytics reporting. 

Right, you need to encode it in the URL. Are you saying the ability to construct a POST request is the only feature missing from the existing platform? (IMG and <a ping> requires you to encode the information in the URL.)

We need a reliable mechanism to upload arbitrary payloads without blocking the UA and being cancelled across navigations. 

- Semantically, POSTing data is the right mechanism.

- Encoding data in a URL places hard limits on size of payload (that, and that's not what URLs are for...)

A bit of background...

In the early stages of the discussion I reached out to go Google Analytics team to see how they solve this problem today. Answer: sync XHRs and payloads of up to 10KB (this is already outside of URL-encoding reach). When we proposed adding a 10KB limit on uploads to ensure that these beacons don't interfere with next navigation (something that IE team was worried about), others piped up citing examples where they have uploads in 20KB+ territory (e.g. error reports with stack traces). As a result, the decision was to omit specifying a payload limit in v1, but reserve the right to add it in the future version of the spec (pending real world experience). 

Reliability of delivery was the other big concern. The language in the spec is intentionally loose: the consensus was that without implementation experience we can't provide any specific guarantees, but that the UA *can* (read should/will) go the extra mile to ensure that the beacon is delivered. This may mean postponing it, retrying delivery, etc. Once again, this could be a UA specific strategy, or if some universal pattern emerges later, we can update the spec to include that... In my books, if Beacon does not improve delivery rate, then Beacon has failed.

There was also a round of discussions around aggregating Beacons which would allow the UA to batch / delay multiple beacon requests and fire them off at once to avoid waking the radio on each one. However, to keep things simple, that was omitted (for now?). 

I think the collection of all of the above is why the conclusion was to define Beacon as a standalone API as opposed to decorating XHR with an extra "ignoreResponse" flag. If you omit all payload limits, skip the retries / improving delivery, eliminate aggregation then yeah, XHR flag would do the trick, but it also doesn't give us much wiggle room. In short, I think Beacon is sufficiently different based on above requirements that a standalone API is a reasonable approach.

ig

[Darin Fisher]

Right! My point is that we could make that change to the current backend without any API changes. The issue of beacon reliability is completely orthogonal to the API used to construct the beacon. Just want to make sure we focus on why the new API matters. It doesn't have anything to do with beacon reliability.

-Darin 

[Darin Fisher]

On Wed, Apr 16, 2014 at 6:34 PM, Ilya Grigorik <igri...@google.com> wrote:

On Wed, Apr 16, 2014 at 4:18 PM, Darin Fisher <da...@chromium.org> wrote:

On Wed, Apr 16, 2014 at 4:03 PM, Ilya Grigorik <igri...@google.com> wrote:

On Wed, Apr 16, 2014 at 2:40 PM, Darin Fisher <da...@chromium.org> wrote:

I agree that Beacon API is easier to use. I think my question gets to the motivation for Beacon API.

Is it that web developers do not understand that they can use <a ping> in this way that they do not? Or, do we know that they do not? You didn't mention <a ping> in the motivation section.

<a ping> does not allow me to POST data, which is one of the primary use cases for a lot of analytics reporting. 

Right, you need to encode it in the URL. Are you saying the ability to construct a POST request is the only feature missing from the existing platform? (IMG and <a ping> requires you to encode the information in the URL.)

We need a reliable mechanism to upload arbitrary payloads without blocking the UA and being cancelled across navigations. 

- Semantically, POSTing data is the right mechanism.

- Encoding data in a URL places hard limits on size of payload (that, and that's not what URLs are for...)

A bit of background...

In the early stages of the discussion I reached out to go Google Analytics team to see how they solve this problem today. Answer: sync XHRs and payloads of up to 10KB (this is already outside of URL-encoding reach). When we proposed adding a 10KB limit on uploads to ensure that these beacons don't interfere with next navigation (something that IE team was worried about), others piped up citing examples where they have uploads in 20KB+ territory (e.g. error reports with stack traces). As a result, the decision was to omit specifying a payload limit in v1, but reserve the right to add it in the future version of the spec (pending real world experience). 

It seems odd to place a limit retroactively. That could break existing users.

Reliability of delivery was the other big concern. The language in the spec is intentionally loose: the consensus was that without implementation experience we can't provide any specific guarantees, but that the UA *can* (read should/will) go the extra mile to ensure that the beacon is delivered. This may mean postponing it, retrying delivery, etc. Once again, this could be a UA specific strategy, or if some universal pattern emerges later, we can update the spec to include that... In my books, if Beacon does not improve delivery rate, then Beacon has failed.

Like I mentioned elsewhere on this thread, we already have loads of experience with beacons, just not this particular way of constructing beacons. The reliability subject is something we could work on independently of Beacon API.

 

There was also a round of discussions around aggregating Beacons which would allow the UA to batch / delay multiple beacon requests and fire them off at once to avoid waking the radio on each one. However, to keep things simple, that was omitted (for now?). 

I think the collection of all of the above is why the conclusion was to define Beacon as a standalone API as opposed to decorating XHR with an extra "ignoreResponse" flag. If you omit all payload limits, skip the retries / improving delivery, eliminate aggregation then yeah, XHR flag would do the trick, but it also doesn't give us much wiggle room. In short, I think Beacon is sufficiently different based on above requirements that a standalone API is a reasonable approach.

Yeah, I really like the idea of the UA getting to know that the web developer is trying to send a beacon.

OK, I'm convinced. Beacon API sounds good to me.

Implementation note: In Chromium, "beacons" are currently issued to the browser process a network requests of type ResourceType::PING. This is used for <a ping>, images started during unload, and I think it should also be used by Beacon API. We should then explore how to make ResourceType::PING more reliable. If we don't do the latter, then I don't think anyone will be happy using Beacon API.

-Darin

[Alex Russell]

I'd strongly caution against further hacks that require programmatic driving of the declarative API to get things done. It's antithetical to layering. I support this API as a targeted intervention that can, in future, in turn be explained by a series of XHR or fetch() flags.

LGTM

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jonas Sicking]

Adding this to XHR was discussed on public-webapps but was decided against.

This would introduce a completely new "mode" for XHR which
* Doesn't terminate the network request when the user leaves the page.
* Can be delayed at will by the UA in order to save battery or
prioritize more urgent network requests (such as a loading page).
* Doesn't fire any events.

This seems like a pretty big departure from current XHR behavior. This
might be worth it if it brought other big advantages. However XHR is
both a commonly despised API which people prefer to wrap than use
directly. It's also a pretty complex API which requires three function
calls in order to fire off a request (including the constructor call).

These issues are severe enough that we're considering replacing it
with a new fetch() API in order to fix up it's various issues. If this
happens (and it's already started in the service worker spec) then
compatibility with XHR brings even less benefit.

/ Jonas

[Eric Seidel]

I'm sold on both why existing beacons don't cut it (lack of POST,
benefits from explicit author intent) and why it's different from XHR
(possibly delay, outlive the page, etc.). Thanks for the explanations
all.

LGTM

[Ilya Grigorik]

On Wed, Apr 16, 2014 at 9:18 PM, Darin Fisher <da...@chromium.org> wrote:

Yeah, I really like the idea of the UA getting to know that the web developer is trying to send a beacon.

OK, I'm convinced. Beacon API sounds good to me.

Implementation note: In Chromium, "beacons" are currently issued to the browser process a network requests of type ResourceType::PING. This is used for <a ping>, images started during unload, and I think it should also be used by Beacon API. We should then explore how to make ResourceType::PING more reliable. If we don't do the latter, then I don't think anyone will be happy using Beacon API.

+1

[Sigbjorn Finne]

Den 17.04.2014 17:24, skreiv Eric Seidel:
> I'm sold on both why existing beacons don't cut it (lack of POST,
> benefits from explicit author intent) and why it's different from XHR
> (possibly delay, outlive the page, etc.). Thanks for the explanations
> all.
>

Ditto, a number of issues teased apart in this thread.

FTR, <a ping> occurrences are tracked by this use counter,

http://www.chromestatus.com/metrics/feature/timeline/popularity/276

--sigbjorn

[Chris Bentzel]

I'm glad that the beacon spec allows UA to do size caps when calling sendBeacon, particularly if we plan to persist these across restarts. 

However, there's no specified cap in the spec. I worry that developers are going to have reverse-engineer sizes provided by the UAs, especially since truncation is not handled under the hood. Are there plans to make this more clear?

Also agree with Darin about how to hook this up browser side, and that work here will benefit all three APIs.

[William Chan (陈智昌)]

Did anyone address Darin's point here? I agree with Darin's analysis on the orthogonal nature of API and beacon reliability. If the beacon API authors believe otherwise, it'd be very useful to hear why.

 

-Darin 

[Ilya Grigorik]

On Thu, Apr 17, 2014 at 12:27 PM, Chris Bentzel <cben...@chromium.org> wrote:

I'm glad that the beacon spec allows UA to do size caps when calling sendBeacon, particularly if we plan to persist these across restarts. 

However, there's no specified cap in the spec. I worry that developers are going to have reverse-engineer sizes provided by the UAs, especially since truncation is not handled under the hood. Are there plans to make this more clear?

"If the User Agent limits the amount of data that can be queued to be sent using this API and the size of data causes that limit to be exceeded, this method returns false."

The decision as to what makes a reasonable cutoff is deferred to the UA. In theory this also allows the UA to adapt / change the cutoff based on environment conditions - e.g. spotty connection or user on a roaming ($$$) plan, etc. That said, I'd expect that most UAs would converge on some ~common defaults.

I think so? We should make both <a ping> and Beacon more reliable. 

ig

[Darin Fisher]

On Fri, Apr 18, 2014 at 12:38 PM, Ilya Grigorik <igri...@google.com> wrote:

On Thu, Apr 17, 2014 at 12:27 PM, Chris Bentzel <cben...@chromium.org> wrote:

I'm glad that the beacon spec allows UA to do size caps when calling sendBeacon, particularly if we plan to persist these across restarts. 

However, there's no specified cap in the spec. I worry that developers are going to have reverse-engineer sizes provided by the UAs, especially since truncation is not handled under the hood. Are there plans to make this more clear?

"If the User Agent limits the amount of data that can be queued to be sent using this API and the size of data causes that limit to be exceeded, this method returns false."

The decision as to what makes a reasonable cutoff is deferred to the UA. In theory this also allows the UA to adapt / change the cutoff based on environment conditions - e.g. spotty connection or user on a roaming ($$$) plan, etc. That said, I'd expect that most UAs would converge on some ~common defaults.

Maybe our implementation should randomize this limit intentionally to force authors to cope with variability here? Otherwise, we'll have no hope of altering limits once developers discover the fixed limits of UAs.

 

On Thu, Apr 17, 2014 at 12:51 PM, William Chan (陈智昌) <will...@chromium.org> wrote:

On Wed, Apr 16, 2014 at 9:07 PM, Darin Fisher <da...@chromium.org> wrote:

Right! My point is that we could make that change to the current backend without any API changes. The issue of beacon reliability is completely orthogonal to the API used to construct the beacon. Just want to make sure we focus on why the new API matters. It doesn't have anything to do with beacon reliability.

Did anyone address Darin's point here? I agree with Darin's analysis on the orthogonal nature of API and beacon reliability. If the beacon API authors believe otherwise, it'd be very useful to hear why.

I think so? We should make both <a ping> and Beacon more reliable. 

And, image loaded from unload? I see no reason to leave that out since people already use it. (It would be more work to make it different.)

-Darin

[Sigbjorn Finne]

Den 18.04.2014 21:47, skreiv Darin Fisher:
> On Fri, Apr 18, 2014 at 12:38 PM, Ilya Grigorik <igri...@google.com>wrote:
>
>>
>> On Thu, Apr 17, 2014 at 12:27 PM, Chris Bentzel <cben...@chromium.org>
>> wrote:
>>
>> I'm glad that the beacon spec allows UA to do size caps when calling
>>> sendBeacon, particularly if we plan to persist these across restarts.
>>>
>>> However, there's no specified cap in the spec. I worry that developers
>>> are going to have reverse-engineer sizes provided by the UAs, especially
>>> since truncation is not handled under the hood. Are there plans to make
>>> this more clear?
>>>
>>

>> *"If the User Agent limits the amount of data that can be queued to be

>> sent using this API and the size of data causes that limit to be exceeded,

>> this method returns false."*

>>
>> The decision as to what makes a reasonable cutoff is deferred to the UA.
>> In theory this also allows the UA to adapt / change the cutoff based on
>> environment conditions - e.g. spotty connection or user on a roaming ($$$)
>> plan, etc. That said, I'd expect that most UAs would converge on some
>> ~common defaults.
>>
>
> Maybe our implementation should randomize this limit intentionally to force
> authors to cope with variability here? Otherwise, we'll have no hope of
> altering limits once developers discover the fixed limits of UAs.
>

The Mozilla implementation has no limits on the total data queued nor
individual beacon size, afaict from the patch
(https://bugzilla.mozilla.org/show_bug.cgi?id=936340)

--sigbjorn

[Chris Bentzel]

Interesting. You could imagine that it would be very easy for a site to issue a ton of beacons since the call completes immediately. Probably needs some sort of quota enforcement in practice (and as the spec allows).

[Ilya Grigorik]

On Fri, Apr 18, 2014 at 12:47 PM, Darin Fisher <da...@chromium.org> wrote:

I think so? We should make both <a ping> and Beacon more reliable. 

And, image loaded from unload? I see no reason to leave that out since people already use it. (It would be more work to make it different.)

Personally, I don't think <img> in unload is something we should worry about:

a) (ab)using img as a beacon is, well, just that.. abusing <img>.

b) we should give developers a nudge towards using <a ping> (lightweight click analytics) and Beacon API (reporting structured data, etc). 

The UA benefits from the implicit signal of <a ping> / Beacon: we know that the response does not matter, we can defer / retry, give these requests a different priority, etc.

ig

[Darin Fisher]

Yeah, I'd prefer people use more explicit mechanisms as well. however, it is much simpler for us to treat all 3 as the same. Does it really hurt to treat them the same?

Folks use the IMG trick in IE, going way back to older versions. The other APIs aren't available in IE.

-Darin

[Ilya Grigorik]

On Fri, Apr 18, 2014 at 2:09 PM, Darin Fisher <da...@chromium.org> wrote:

Folks use the IMG trick in IE, going way back to older versions. The other APIs aren't available in IE.

IE folks have been actively involved in Beacon discussions and at least as far as I can tell are planning to implement Beacon. Their (new) status page lists it as "under consideration": http://status.modern.ie/beacon

That said, I'm not against applying similar treatment to <img>.. it's just that I'd prefer that we nudge developers towards better APIs and see <img> as a low priority item.

ig

[Darin Fisher]

Maybe a compromise is that we should only talk about Beacon then ;-)

-Darin

[Ilya Grigorik]

On Fri, Apr 18, 2014 at 2:29 PM, Darin Fisher <da...@chromium.org> wrote:

Maybe a compromise is that we should only talk about Beacon then ;-)

I'm good with that! :)

[Sigbjorn Finne]

This intent has one (clear&stated) LGTM against it afaict. I will consider
re-initiating it later should the case for Beacon become stronger.

--sigbjorn

[Ilya Grigorik]

On Mon, Apr 28, 2014 at 11:50 AM, Sigbjorn Finne <s...@opera.com> wrote:

This intent has one (clear&stated) LGTM against it afaict. I will consider
re-initiating it later should the case for Beacon become stronger.

I'd love to keep this moving forward. I think we hashed out a lot of different questions in this thread and my impression is that we're higher than one LGTM.. Could we do another pass?

darrin@, abarth@: what are your thoughts? Any outstanding issues?

ig

[Darin Fisher]

No need to seek out "LGTM"s for an intent to implement. I think there is plenty of support to implement in Blink.

-Darin

[Ojan Vafai]

To clarify a bit more, intent to implements are about making the Blink community aware of work starting on a feature and it gives an early opportunity for Blink developers to voice concerns they have with the feature. We rely on reviewers to use their regular judgement about whether a specific patch is OK.

The formal 3 LGTMs from API owners are only needed for intent to ships. Ideally at that point all the concerns will have been addressed already since the community will have had ample opportunity to express their concerns.

In this specific case, +1 to continuing implementation. It seems to me all the concerns expressed on this thread have been addressed, we clearly want this feature and the appropriate level of standards due diligence has been done.

[Sigbjorn Finne]

Den 30.04.2014 02:07, skreiv Ojan Vafai:
> To clarify a bit more, intent to implements are about making the Blink
> community aware of work starting on a feature and it gives an early
> opportunity for Blink developers to voice concerns they have with the
> feature. We rely on reviewers to use their regular judgement about whether
> a specific patch is OK.
>
> The formal 3 LGTMs from API owners are only needed for intent to ships.
> Ideally at that point all the concerns will have been addressed already
> since the community will have had ample opportunity to express their
> concerns.
>
> In this specific case, +1 to continuing implementation. It seems to me all
> the concerns expressed on this thread have been addressed, we clearly want
> this feature and the appropriate level of standards due diligence has been
> done.
>

Thanks Ojan,

that clarifies, both for this intent and to others (I hope.) I will proceed
with a CL.

Multiple LGTM-to-proceed on an intent-to-implement are helpful signals
though to both the proposer and reviewers, I think.

--sigbjorn