Re: [Beacon] spec feedback + few suggestions

I agree with what Jonas says about online/offline.  Anyone who has written
websites for use over mobile networks will tell you that the only way to be
absolutely certain that a request was successful is to look at its response.

The way I see it is that there are 3 options for handling failure:
1) Don't handle failure. (Assume that all requests which were sent,
eventually get received.)
2) Allow the developer to handle failure. (eg callbacks, through a
ServiceWorker or enumerating failed beacons)
3) Get the User Agent to handle failure.

Number 1 only works if your network is 100% perfect, or you don't care
about losing an unknown amount of data (not ideal for analytics).
Number 2 goes against the whole notion of fire-and-forget.
Number 3 would require a standardised definition of what exactly we count
as "failure".

Obviously you can have combinations of the above, (eg "try number 3 for x
seconds, then do number 1"), but then you'll end up having to deal with the
problems of both of the options you've combined.



On 12 November 2013 00:39, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Nov 12, 2013 at 5:17 AM, Ilya Grigorik <igrigorik@google.com>
> wrote:
> >> navigation.onLine isn't reliable.  It just means that the device thinks
> >> it's connected to something. That something could be a wifi router with
> no
> >> internet connection, a 3g connection with such high latency that no
> requests
> >> succeed or a captive portal.  By no means does it mean that any given
> future
> >> request is going to succeed.
> >
> > If navigator.onLine isn't reliable, then that's a bug and it should be
> > addressed at that layer.
>
> It's impossible to make navigator.onLine reliable. The last time the
> device did a ping to the radio tower it could have responded that you
> are still connected, however since then you might have lost connection
> without having discovered that through another radio ping.
>
> Even when connected over wifi or ethernet you can't really implement
> reliable navigator.onLine. Last time you sent a packet your
> connectivity might have been fine. But since then something broke
> between your router and the outside internet. You won't know that
> until the next time you attempt to make a request.
>
> >> A ServiceWorker can't predict whether a request is going to succeed any
> >> better than javascript calling ajax can.  So to see whether a request
> >> actually succeeded, the ServiceWorker would need to look at the
> response of
> >> the beacon request coming back from the server.  Doesn't this defeat the
> >> whole "fire-and-forget" idea behind beacon?
> >
> >
> > SW will obviously need a mechanism to distinguish whether the UA is
> online
> > or offline.. if it doesn't, then what's the point of SW?
>
> SW won't reliably know if it's online. The suggested behavior for SW
> is to use local data first. If needed you then kick off a network
> request, and if that comes back with newer data trigger a refresh (of
> whatever data was requested, not a full-page reload).
>
> >>> - if the UA is offline and gets a sendBeacon(), it can hold it for some
> >>> short period of time (with hope that UA will come online shortly), and
> then
> >>> release it regardless of connection state.. if there is no SW to
> intercept
> >>> it and the UA is offline, then beacon is dropped.
> >>
> >> Seeing as one of the primary use cases for this is analytics, I don't
> >> think many people will be happy with requests being dropped.
> >
> > This is no worse than what happens today - e.g. your connection drops,
> your
> > beacons drop.. unless you've built additional logic to address this.
>
> The problem is that with beacon you can't build logic to address it
> due to the fire-and-forget nature.
>
> Maybe we should add API which enables enumerating failed and/or
> succeeded beacons?
>
> / Jonas
>



-- 
Luke Blaney
Labs developer, FT Labs [labs.ft.com | 0870 085 2038 | @ftlabs]

-- 

------------------------------
This email was sent by a company owned by Pearson plc, registered office at 
80 Strand, London WC2R 0RL.  Registered in England and Wales with company 
number 53723.