FYI: Resource Priorities and Beacon API

2013-10-30 Thread Philippe Le Hegaret
FYI, the Web Performance Working Group just published Resource Priorities and Beacon yesterday and we're interested in feedback on the ideas and approaches. Resource priorities allows you to tweak the download priority of your resources, while Beacon enables synchronously transfer data from the

Re: FYI: Resource Priorities and Beacon API

2013-10-30 Thread Philippe Le Hegaret
On Wed, 2013-10-30 at 13:23 -0400, Philippe Le Hegaret wrote: FYI, the Web Performance Working Group just published Resource Priorities and Beacon yesterday and we're interested in feedback on the ideas and approaches. Resource priorities allows you to tweak the download priority of your

Re: Beacon API

2013-02-20 Thread James Graham
On 02/20/2013 08:24 AM, Reitbauer, Alois wrote: My personal experience is different. We found that using img tags is not that reliable. Especially in Firefox we recently saw some problems. Img tags in general have the disadvantage that the amount of data that can be set is rather limited. While

Re: Beacon API

2013-02-18 Thread Anne van Kesteren
On Sat, Feb 16, 2013 at 11:36 AM, Reitbauer, Alois alois.reitba...@compuware.com wrote: 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

Re: Beacon API

2013-02-18 Thread Reitbauer, Alois
From my perspective the point is that we should rather have a clear(er) definition of what we need, rather than starting to see how it fits into existing specs. Having this initial spec it will be also easier to decide about the actual fit into XHR or PING // Alois On 2/18/13 10:19 AM, Anne van

Re: Beacon API

2013-02-18 Thread Anne van Kesteren
On Mon, Feb 18, 2013 at 4:10 PM, Reitbauer, Alois alois.reitba...@compuware.com wrote: From my perspective the point is that we should rather have a clear(er) definition of what we need, rather than starting to see how it fits into existing specs. Having this initial spec it will be also easier

Re: Beacon API

2013-02-17 Thread Andy Davies
On 16 February 2013 05:25, Maciej Stachowiak m...@apple.com wrote: BTW as far as I know the best current nonblocking technique to phone home on unload is to create an img in your unload handler pointing to the ping URL, this will result in reliable delivery without blocking at least in IE

RE: Beacon API

2013-02-16 Thread Reitbauer, 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

Re: Beacon API

2013-02-15 Thread Anne van Kesteren
On Fri, Feb 15, 2013 at 12:21 AM, Ilya Grigorik igrigo...@google.com wrote: A lot of the discussion so far focused on the async analytics beacon + unload use case. However, while this is an important case to consider, let's not constrain this proposal to on unload case only. Just to be clear.

Re: Beacon API

2013-02-15 Thread イアンフェッティ
Anne, Both Chrome and Safari support the ping attribute. I am not sure about IE, I believe Firefox has it disabled by default. FWIW I wouldn't consider this a huge failure, if anything I'd expect over time people to use ping where it's supported and fallback where it's not, resulting in the same

Re: Beacon API

2013-02-15 Thread Ilya Grigorik
On Fri, Feb 15, 2013 at 3:06 AM, Anne van Kesteren ann...@annevk.nl wrote: Just to be clear. I understand why we'd want this. I'm a) wondering why it'll be successful this time given it has the same characteristics as ping= b) asking about the desired timeframe given the highly likely

RE: Beacon API

2013-02-15 Thread Jatinder Mann
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

Re: Beacon API

2013-02-15 Thread Maciej Stachowiak
On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) ife...@google.com wrote: Anne, Both Chrome and Safari support the ping attribute. I am not sure about IE, I believe Firefox has it disabled by default. FWIW I wouldn't consider this a huge failure, if anything I'd expect over time people

Re: Beacon API

2013-02-15 Thread Maciej Stachowiak
On Feb 15, 2013, at 9:21 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 15, 2013, at 3:51 AM, Ian Fette (イアンフェッティ) ife...@google.com wrote: Anne, Both Chrome and Safari support the ping attribute. I am not sure about IE, I believe Firefox has it disabled by default. FWIW I

Re: Beacon API

2013-02-14 Thread Reitbauer, Alois
this problem, the Web Performance WG has included writing a Beacon API in its charter [1]. This API would be an interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with a guarantee from the user agent that the data will be eventually sent

Re: Beacon API

2013-02-14 Thread Reitbauer, Alois
Anne, Some more details that should help to clarify: You are right we would not need any progress events and you are also typically not interested in the response. The server should normally reply only with a no content reply. Conceptually this reply would not be needed, however, HTTP requires

Re: Beacon API

2013-02-14 Thread Anne van Kesteren
On Thu, Feb 14, 2013 at 9:55 AM, Reitbauer, Alois alois.reitba...@compuware.com wrote: You are right we would not need any progress events and you are also typically not interested in the response. The server should normally reply only with a no content reply. Conceptually this reply would not

Re: Beacon API

2013-02-14 Thread Reitbauer, Alois
...@opera.com, public-webapps@w3.orgmailto:public-webapps@w3.org public-webapps@w3.orgmailto:public-webapps@w3.org, Alois Reitbauer alois.reitba...@compuware.commailto:alois.reitba...@compuware.com Subject: Re: Beacon API On Wed, Feb 13, 2013 at 11:45 AM, Tab Atkins Jr. I started a thread last year

Re: Beacon API

2013-02-14 Thread Reitbauer, Alois
In the cases I see we are never interested in the response. The question would also be how to handle it as the page that initiated it might - or will - no longer be there. I do not see how this relates to the ping. If I understand the Ping correctly it send back the ping when a ling was clicked.

Re: Beacon API

2013-02-14 Thread Anne van Kesteren
On Thu, Feb 14, 2013 at 12:28 PM, Reitbauer, Alois alois.reitba...@compuware.com wrote: I do not see how this relates to the ping. If I understand the Ping correctly it send back the ping when a ling was clicked. The scenario here is totally different. An analytics tool - whether RUM or other

Re: Beacon API

2013-02-14 Thread Reitbauer, Alois
What exactly do you mean by failed. Was nobody interested in it? On 2/14/13 1:34 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 14, 2013 at 12:28 PM, Reitbauer, Alois alois.reitba...@compuware.com wrote: I do not see how this relates to the ping. If I understand the Ping correctly

Re: Beacon API

2013-02-14 Thread Anne van Kesteren
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

Re: Beacon API

2013-02-14 Thread Ilya Grigorik
A lot of the discussion so far focused on the async analytics beacon + unload use case. However, while this is an important case to consider, let's not constrain this proposal to on unload case only. Effectively, what we want is a generic send this request sometime later, I don't care when, where

Beacon API

2013-02-13 Thread Jatinder Mann
a Beacon API in its charter [1]. This API would be an interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with a guarantee from the user agent that the data will be eventually sent. However, instead of inventing a new way to send data, it may

Re: Beacon API

2013-02-13 Thread Julian Aubourg
writing a Beacon API in its charter [1]. This API would be an interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with a guarantee from the user agent that the data will be eventually sent. ** ** However, instead of inventing a new

Re: Beacon API

2013-02-13 Thread Tab Atkins Jr.
opportunities. To solve this problem, the Web Performance WG has included writing a Beacon API in its charter [1]. This API would be an interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with a guarantee from the user agent that the data

Re: Beacon API

2013-02-13 Thread Anne van Kesteren
On Wed, Feb 13, 2013 at 4:03 PM, Jatinder Mann jm...@microsoft.com wrote: How interested is this working group in taking on such work in the XHR Level 2 specification? There's plans to develop a better API for XMLHttpRequest, that would be somewhat more object-oriented, use DOMFuture, etc., but

Re: Beacon API

2013-02-13 Thread Dave Methvin
On Wed, Feb 13, 2013 at 11:45 AM, Tab Atkins Jr. I started a thread last year in WHATWG about this subject, though from a slightly different angle: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/035686.html . A new simple API sounds like the best solution. Adding a