Re: Request to summarize overall `state` of each spec

On 01 Nov 2013, at 08:36, Wonsuk Lee <wonsuk11.lee@samsung.com> wrote:

> Hi. Editors!
> Before F2F meeting in China, could you please summarize overall state of the spec you are developing? E.g. status, major issues, next steps, etc.
> It would be very helpful for our meeting, because candidate attendees could understand status of the spec and could think about major issues indicated before discussion in f2f.

The current status re the Application Lifecycle and Events spec [1] is as follows:

* Changes since the Toronto F2F:

- The feedback provided at the meeting has been incorporated into the spec. For details, see [2]
- The spec now builds atop ServiceWorker [3], extends ServiceWorkerScope
- The taskScheduler attribute of the ServiceWorkerScope interface returns an instance of the TaskScheduler interface [4]

(Please note the normative parts of the spec are not yet fully aligned with the ServiceWorker's model, or complete. E.g. the Application Events should be fired at the ServiceWorkerScope. We’ll align as the ServiceWorker itself stabilises.)

* Open issues:

The following open issues would benefit from the group’s feedback and review at the meeting (also annotated in the spec itself):

ISSUE 1: Remove features that do not have strong use cases and consider them in v2. After implementation feedback, we can add features that appear to be lacking. For example, reason in LaunchEvent, terminate and terminatecanceled are proposed to be deferred to v2 without strong use cases.

ISSUE 2: The pending-event, scheduled or other event types are confusing. This should be implied by the event "class" or the event name.

ISSUE 3: Need a mechanism for passing data to the service worker from the application that launched it. Does Web Activities/Intents address the use case (in scope for Web Intents Task Force), or is this addressed by e.g. passing the data in LaunchEvent?

ISSUE 4: Need to make it clear that the service worker can be terminated only when it is idling, all Promises resolved, all indexedDB transactions completed, no Workers running etc. However, Badly behaving application that try to prevent an application for being closed can be killed by the system similarly toonunload.

* Next steps:

- Continue track ServiceWorker, align Application Events with the model
- Flesh out System Event delivery and registration (and/or defer to the ServiceWorker proper?)
- Permission control, need a consistent model that works for ServiceWorkers
- A mechanism for inter-app communication (cf. Web Activities/Intents)
- Bootstrapping a ServiceWorker off of a manifest

Before thinking of formal publication, I'd guess we need to get clarity on how the core dependency (ServiceWorker) is doing in terms of Rec Track, scope.

These are some topics for discussion. See you all next week!

Thanks,

-Anssi

[1] http://www.w3.org/2012/sysapps/app-lifecycle/
[2] http://lists.w3.org/Archives/Public/public-sysapps/2013Sep/0017.html
[3] https://github.com/slightlyoff/ServiceWorker/
[4] http://www.w3.org/2012/sysapps/web-alarms/#interface-taskscheduler

Received on Tuesday, 5 November 2013 09:11:29 UTC