RE: [Beacon] spec feedback + few suggestions

On Oct 30, 2013 2:17 PM, Jonas Sicking wrote:
> 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.

Seeing that it's just a single call with no return values or other state, a function does seem to make more sense here instead of an object. 

On Oct 30, 2013 2:17 PM, Jonas Sicking wrote:
> On Oct 30, 2013 11:36 AM, Jatinder Mann wrote:
>> 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.

Seeing that we may send beacons after unload, this does connect the queue to the UA rather than the page. So navigator isn't a bad fit here.

On Oct 30, 2013 2:17 PM, Jonas Sicking wrote:
> 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.

Since we don't return success or failure, developers will have a higher expectation that data won't be lost. Though, I'm not sure if the spec should recommend that the user agent persist the data in the event that the browser session is ended. This feels like implementation details that we may want to leave to user agents. 

Also, should the spec recommend an expected time frame in which the data will be sent or just leave it as "best effort to send as soon as possible? What about a timeout? Should we specify that if the data isn't sent by X seconds it'll never be sent? Personally, I'd prefer not giving time frames and just leaving it at best effort.

Jatinder

Received on Wednesday, 30 October 2013 22:40:37 UTC