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

Hi. Anssi.
Thanks a lot for good summary.

Concerning to intro of ServiceWorker, I requested this to Alex couple of
days ago. But I didn't receive his answer yet. So if he is not possible,
could you or Kenneth explain this instead of him?

Kr, Wonsuk.

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> Sent: Tuesday, November 05, 2013 6:11 PM
> To: Wonsuk Lee
> Cc: public-sysapps@w3.org; Mounir Lamouri; Dave Raggett
> Subject: 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 11:53:45 UTC