W3C home > Mailing lists > Public > public-sysapps@w3.org > September 2013

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

From: Jungkee Song <jungkee.song@samsung.com>
Date: Mon, 23 Sep 2013 23:34:43 +0900
To: "'Kostiainen, Anssi'" <anssi.kostiainen@intel.com>, 'Marcos Caceres' <w3c@marcosc.com>
Cc: public-sysapps@w3.org, "'Christiansen, Kenneth R'" <kenneth.r.christiansen@intel.com>
Message-id: <03bb01ceb86a$0b61dc50$222594f0$@samsung.com>
> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> On Sep 17, 2013, at 1:51 PM, Marcos Caceres <w3c@marcosc.com> wrote:
> > On Monday, September 16, 2013 at 3:44 PM, Kostiainen, Anssi wrote:
> >
> >> It'd be great if EventWorker would address say 90% of the requirements,
> and only minor extensions would be needed to support packaged apps.
> >
> > That would be great. I can't emphasize enough that there is an urgency
> for this group to get it's use cases and requirements in front of the
> folks currently working on Event Workers. Prototype implementations are
> happening right now in Chrome and Mozilla so we really don't want to miss
> the boat: the folks working on this change focus quickly (it was last week
> they were working on Promises, and next week they could switch to
> something else).
> [...]
> On an initial scan the API proposal LGTM considering the needs of this
> group:
>   https://github.com/slightlyoff/EventWorker/blob/master/event_worker.ts
> I'll be evaluating it in more detail against the use cases the group has
> identified.

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

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

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

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

Jungkee Song
Received on Monday, 23 September 2013 14:35:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:15 UTC