W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2017

Re: Re: Generalization of Service Worker external events

From: Andy Valencia <ajv-efurgetonrit@vsta.org>
Date: Fri, 7 Apr 2017 21:59:46 +0000 (UTC)
To: (wrong string) รกlez@vsta.org
Cc: public-webapps@w3.org
Message-Id: <20170407215946.C6FF64030B@vsta.org>
> If I did not understand wrong, such generalisation already exists. The
> events that can wake a SW up are called Functional Events and are a point
> of extension.
> ...
> It is not clear to me what do you mean when saying that Service Workers
> expose a RESTful API. Sure you can user `fetch` to implement a RESTful API
> but other functional events use their own mechanisms.

The dominance of RESTful API's makes my default approach shift once
I have them available.  You are quite correct that it is just one
possible API for SW.

> Here is the spec: https://www.w3.org/TR/service-workers/#extension-to-
> extendable-event

Thank you for bringing my question neatly to the key point.  With
respect to extensions, the issue is how to implement long polling
within a Service Worker?

While the registering client is around, it's not hard to keep
long-running fetches posted.  The real value is to have the service
worker maintain long polling in the background across client closures
and SW stop/start cycles.

"background fetch" is very close to the needed mechanism.

Missing parts:
    Timeout
    Serial fetch re-posting until "real" completion
     With parameters for this re-posting behavior
    Inhibit TCP level timeout (you have to do HTTP-level
     timeout and failure to be reliable anyway)

I imagine a web application can lose its tab, the SW is stopped, and
the long polling continues quietly at the OS level, just as in a
background fetch it is the long/large fetch which does this.

(BTW, on both mobile Firefox and Android this is very battery
efficient).

Minutes or hours later, a "real" completion can kick the
web application (or perhaps just its SW) back to life.

Based on feedback, I'd be very interested in trying my hand at
a minimalist adjunct to the background fetch document
to support long polling.  I think it could be done with
just a few additional options to the background fetch API.

Alternatively, I could write a separate document describing an
extension to support long polling type network functions.  The latter
seems like overkill, but have text editor, will travel.

Long polling is a very powerful, very efficient technique
for maintaining telemetry, be it presence, push, sensors,
or any other real time event in either direction.  It also
adapts to a wide variety of networks, topologies, and server
and firewall deployments.  I hope I can interest this group
in enabling these techniques within Service Workers.  Long
Polling and Service Workers seem like a natural fit.

Sincerely,
Andy Valencia
Received on Friday, 7 April 2017 22:00:15 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:42 UTC