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 [jm...@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.


-----Original Message-----
From: annevankeste...@gmail.com [mailto:annevankeste...@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.reitba...@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.)


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.

Reply via email to