- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 12 Feb 2014 14:52:56 -0800
- 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