Re: Generalization of Service Worker external events

Hi Andy

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. Indeed, `fetch` is one this events but you have other such a
`push`, `sync` or `notificationclick`.

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.

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

Hope it helps.

On Wed, Mar 29, 2017 at 4:04 AM, Andy Valencia <ajv-efurgetonrit@vsta.org>
wrote:

> Service Workers ("SW") were obviously initially motivated by the
> need for a more flexible offline app architecture.
>
> Because they do not share the DOM of the original registration,
> they are much lighter weight.  Thus, it is reasonable for their
> continued existence even after the (possibly automated) clearing
> of the original registration page.
>
> To defend against various zombie-ware abuses, their state is forced
> inactive soon after the associated page goes away.
>
> In pursuit of an approach for presence and notification dispatch,
> they were enhanced to support returning to run state from a
> (browser specific, possibly proprietary) push event.  (They were
> also given a Notification API to make these events visible.)
>
> Would there be any interest in generalizing the ability to
> resume a SW from remote events?  I'm mostly thinking in terms
> of accomodating long polling techniques, but most important
> is that whatever's used is open and decentralised.
>
> One approach would be to have Notification.requestPermission
> accept a "server" option.  Either a SW with an active fetch
> to that server is left in run state, or perhaps the SW
> can be stopped while maintaining the pending fetch.
>
> Alternatively, Chrome's "background fetch" is actually a pretty
> good fit; just run long polling across its managed fetches.
> Of course, there might be some puzzled users on seeing your
> long polling app listed under the "active downloads" list.
> But in terms of technology mechanism, it's a very good fit.
>
> Service Workers started as a flexible caching solution, but they
> really are just a lightweight background thread with a RESTful API.
> Given a little more app control over their background operation, they
> could become a very flexible, very powerful agent serving the main
> web app while it is in the background, during network interruptions,
> and also low memory situations where the app's tab has been retired.
>
> While, of course, keeping them from becoming soul-sucking zombies.
>
> Thanks,
> Andy Valencia
>
>
>