Re: [runtime] Application Lifecycle and Events - F2F feedback incorporated

Hi Jungkee, All,

On Sep 23, 2013, at 5:34 PM, Jungkee Song <jungkee.song@samsung.com> wrote:

> As of now, I've come up with the following discussion points:

Thanks for your comments.

> - Background service with no UI:
>  As ServiceWorkers are bootstrapped during page loading -
> registerServiceWorker() - the default page should be always present.

Using "vanilla" ServiceWorkers, a user must visit a page for the ServiceWorker installation process to start, and the page must be reloaded before an instance of the ServiceWorker is started. This is as per "the first rule of ServiceWorkers".

However, if a ServiceWorker could be bootstrapped off of a manifest, that would not be the case. Feasibility and implications of this should be explored.

> In my
> perspective, background service with no UI must be scoped in SysApps
> execution model having use cases such as notification (email, persistent
> system event, etc.), data sync, scheduled event, etc.

I assume you mean APIs for persistent system events, scheduled events etc. must be exposed to ServiceWorker scripts?

These features fall within the scope of SysApps, and may or may not be good fit for the open Web, at least not yet. Thus for SysApps purposes there may be a need to extend ServiceWorker.

> - Lifecycle events
>  In my understanding, ServiceWokers may be killed by UA at any time but
> that does not terminate the entire app, i.e. the documents registered the
> worker. In case we happen to work on top of ServiceWorkers, the definition
> of the app should be shared between the two parties. (I presume it's not a
> trivial topic as the current ServiceWorkers allow combination of the
> multiple ServiceWorkers for multiple scopes.)

As Kenneth mentioned, this is similar to the Event Page model, which seems to behave reasonably in the real world. In your example, the implementation would do its best to try keep the associated ServiceWorker(s) alive if there are open windows. 

> - Reason for launch event
>  ServiceWorkers provide oninstall event but it's all after the document
> (UI) has been being loaded. This makes it impossible to adjust the UI
> depending on the reasons.


If a ServiceWorker could be bootstrapped off of a manifest, this would not be an issue.

To summarize the gaps (not a complete list):

* bootstrap a ServiceWorker off of a manifest
* expose APIs for persistent system events, scheduled events etc. to ServiceWorker scripts

All - other major gaps?

Thanks,

-Anssi

Received on Tuesday, 1 October 2013 13:04:50 UTC