W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2017

Re: Generalization of Service Worker external events

From: Salvador de la Puente González <salva@unoyunodiez.com>
Date: Thu, 30 Mar 2017 15:20:51 +0800
Message-ID: <CA+tDh5UNQ6pJxFU14w_a-CXaom4V5oLtzGQqJLQtN0f+g2YUOA@mail.gmail.com>
To: Andy Valencia <ajv-efurgetonrit@vsta.org>
Cc: public-webapps@w3.org
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
>
>
>
Received on Thursday, 30 March 2017 07:22:14 UTC

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