W3C home > Mailing lists > Public > public-web-perf@w3.org > February 2014

Re: [beacon] Random comments

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 12 Feb 2014 14:52:56 -0800
Message-ID: <CA+c2ei-gc3MvUZUDqfW_sF5y7E58Zgvo4hx1Uzk3xaN9DmEVwQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Arvind Jain <arvind@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-web-perf <public-web-perf@w3.org>
On Wed, Feb 12, 2014 at 2:43 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Wed, 12 Feb 2014, Arvind Jain wrote:
>>
>> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html#sec-processing-model
>>
>> Simon suggested changing the processing model to the text pasted below.
>> Subsequent to that, the question was which "settings" object to use -
>> the entry settings object or the incumbent settings object.
>
> It depends on what results you want. Suppose a script in a page with URL A
> calls a function in a page with URL B which calls sendBeacon() on the
> Navigator object of a third page with URL C. Do you want the URL passed to
> sendBeacon() to be resolved relative to A, B, or C?

I really think we want to align all APIs here. Having sendBeacon,
WebSockets and XHR all do different things seems like a bad idea to
me. Especially for authors, but also for spec authors and
implementations.

I personally think C makes the most sense since it doesn't involve
grabbing some omnious global state. Instead the behavior is determined
by the more tangible answer to the question "which object did you call
a function on".

/ Jonas
Received on Wednesday, 12 February 2014 22:53:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:38 UTC