RE: Beacon API

I agree with Jatinder that overloading technologies to do one more thing always created confusion and also makes APIs brittle.

The conversations this week were very helpful in deciding how to move forward. I second Jatinder's idea that we come up with a specification that describes in details what we need. We should also treat it as a separate specification. If we then see that it has enough commonalities with XHR and does not introduce unnecessary complexity we can still merge it.  I also think that this is the most efficient way to move forward here.

// Alois
________________________________________
From: Jatinder Mann [jmann@microsoft.com]
Sent: Saturday, February 16, 2013 12:50 AM
To: Anne van Kesteren; Reitbauer, Alois
Cc: public-webapps@w3.org
Subject: 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/



The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.

Received on Saturday, 16 February 2013 11:37:39 UTC