RE: [Beacon] spec feedback + few suggestions

On Oct 30, 2013 11:36 AM, "Jatinder Mann" <jmann@microsoft.com> wrote:
>
> Thanks Ilya and Jonas for reviewing the spec and putting together this feedback. It would be great if we can discuss the feedback on the mailing list directly to get more visibility.
>
>
>
> > // Move from window.beacon() to navigator.sendBeacon(), or something similar
>
> > // to reduce chance of collision with existing user code.
>
> I have actually heard feedback that the “beacon” name isn’t very clear, and there maybe conflicts with existing “beacons”. What do you think about AsyncSend()? It captures the intention of the API well.

XHR also does an async send though.

However more importantly, the fact that you use an uppercase A makes
me think you are proposing a new class rather than a new function. Is
that right? That somewhat alleviates name clashes, but what would the
syntax be? Simply creating an object and then dropping it on the floor
seems awkward. Introducing a .send function just to have a function to
call is similarly awkward.

I think what we need is a function. And I think that function needs to
live on Navigator to avoid the conflicting requirements of "use a
simple descriptive name" and "don't clash with content functions that
have simple and descriptive names".

I care less about the actual name.

> Looks like navigator is mostly used to share data on the user agent’s state. To reduce conflicts, we can move the AsyncSend/beacon method under the Performance interface? That has the added benefit of implying the method as a performance feature.

This does put the request in a queue that is connected to the UA
rather than the page though. So I think the fit is quite good.

But ultimately I don't care that much.

> The current spec states that the beacon is an “interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with the user agent taking the responsibility to eventually send the data.” This may be confusing as it can be interpreted to mean that we will re-send multiple times. I think we should change the “responsibility” to instead “best effort”. The spec should probably also call out that if the browser session is ended before the beacon is sent, we will not try again.

"Browser session" is getting harder and harder to define though. And I
don't see any benefit to forbidding browsers from persisting beacons
just like they persist form data.

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.

> > In order to keep things simple we could apply the same limitations for same-origin requests as we have for cross-origin requests.
>
> I can understand that we should limit cross-origin verbs to {POST, GET}, but I don’t think we should limit same origin to not use PUT.

I'm certainly ok with follow the patterns here established by other
APIs and let same-origin and cross-origin have different capabilities.

/ Jonas

Received on Wednesday, 30 October 2013 21:17:50 UTC