RE: Beacon API

I worry that overloading the ping attribute here may cause confusion and may not be well adopted for the use case we have presented. 

Let me describe some potential requirements for such an interface. We want an asynchronous method of sending data. The interface shouldn't return a HTTP response, as the expectation is that the user agent would be responsible for sending this data when it could. The user agent must be able to send this data even after the page had unloaded, potentially even attempting to re-send it if the first attempt fails. The interface must support CORS, as one may want to send this data to a different origin. The interface wouldn't be limited to the unload and could be used at any time to reliably send data.

What we wanted to understand was whether it makes more sense to create a XHR variant that does this or if it would just be less confusing to create a new beacon API, as Alois had suggested. 

Considering the requirements, especially if it is only designed to send data and not receive, it may just make more sense to create a specific beacon API here rather than creating a XHR invariant. I think Alois and I should come up with a more concrete proposal and then we can better weigh the pros and cons of the different approaches. 

Thanks,
Jatinder

-----Original Message-----
From: annevankesteren@gmail.com [mailto:annevankesteren@gmail.com] On Behalf Of Anne van Kesteren
Sent: Thursday, February 14, 2013 5:54 AM
To: Reitbauer, Alois
Cc: Jatinder Mann; public-webapps@w3.org
Subject: Re: Beacon API

On Thu, Feb 14, 2013 at 12:38 PM, Reitbauer, Alois <Alois.Reitbauer@compuware.com> wrote:
> What exactly do you mean by failed. Was nobody interested in it?

There was some misguided controversy about the feature and I think that pretty much did it in. It has all the same characteristics as this new proposal, but maybe this one will not get the misguided controversy?

(The controversy was that ping was designed for tracking. That it would improve the situation for the end user over invisible tracking (as this could be disabled) was not taken into account obviously.)


--
http://annevankesteren.nl/

Received on Friday, 15 February 2013 23:53:53 UTC