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

Hi Anssi, all,

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Tuesday, October 01, 2013 10:04 PM
> 
> On Sep 23, 2013, at 5:34 PM, Jungkee Song <jungkee.song@samsung.com>
wrote:
> 
> > - 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".
> 

Yes, indeed. ServiceWorkers require document environment within which the
worker is installed.


> 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.
> 

Although I cannot measure the complexity of the integration (bootstrap a
ServiceWorker from a manifest) as of now, I presume the expected shape would
be a very tightly coupled model requiring huge changes in ServiceWorkers,
which seems not quite a feasible approach. That said, I'd rather try to
think of a loosely-coupled model in that a web app bootstraps a *default
document environment* (index page) in its manifest and the script in the
page installs ServiceWorkers based on its need. This default document plays
its role as the single entry point of the app context creating other
browsing contexts and dispatching persistent events, etc. Also, we can think
of a way to make(allow) this default page invisible to support background
service use cases.


> > 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.
> 

As suggested above, having a default document environment (as a single entry
point) separate from a ServiceWorker environment would make the integration
complexity much lower and also allows ServiceWorker be used in a Webby way
as-is whenever more desirable.


> > - 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.
> 

I don't know whether vanilla ServiceWorkers can handle application-wise
lifecycle events such as onlaunch, onterminate, onpause, onresume. Having a
separate default document (i.e. event page indeed) for lifecycle events
seems to be more flexible, and it seems ServiceWorker has its own unique use
cases: mainly resource request management (fetch and app cache) which are
orthogonal.


> > - 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 Wednesday, 2 October 2013 13:00:45 UTC