Re: app-lifecycle spec

Hi Darmawan,

On Oct 23, 2013, at 2:11 AM, SUWIRYA Darmawan <Darmawan.SUWIRYA@gemalto.com> wrote:

> I’m really sorry for asking this question at the first place. Just wondering if there’s anybody here has seen this :
>  
> https://developers.google.com/chrome/apps/docs/background

No worries, always good to ask.

> It looks to me that what they have there is pretty much answering all the requirements mentioned in the app-lifecycle spec section 4.7.

As Marcos mentioned, ServiceWorker [1] should address the requirements, and provide extensibility hooks to fill in the gaps and address future needs. I'm pretty sure the original authors of the ServiceWorker proposal are aware of the background feature you're referring to.

The app-lifecycle proposal [2] extends ServiceWorker with new events. The way how the lifecycle events are defined in the proposal is not yet fully aligned with the ServiceWorker way of registering and handling events, but the intent is to align. There's no proper ServiceWorker spec draft yet, which makes this a bit hard at the moment.

Anyway, eventually the lifecycle events and any other similar events such as push, alarm etc. could be handled similarly to fetch, install etc. events currently.

> I personally think that their approach in hooking / configuring it up at the manifest level is better rather than bringing in the concept of main() into web-apps like proposed in the app-lifecycle spec.

[What you are referring to with "the concept of main()" or "main document" is just an abstraction used in the context of use cases.]

Instead of invoking registerServiceWorker() in <script> in HTML there could be an entry in the manifest to bootstrap the process -- assuming there will be a stand-alone manifest.

However, I can see the benefits of bootstrapping the ServiceWorker installation process off of an HTML as currently proposed. That might be a better fit for browser-based installable web apps and be more aligned with the web architecture in general.

Perhaps both could coexist.

> Is there any reason why we don’t want to just adopt the similar approach and extend it as per-necessary instead ?

The ServiceWorker proposal is being actively worked on, addresses the requirements, is extensible, and has multiple independent experimental implementations in the works. I think there's enough momentum behind it.

> Another point regarding the section 4.5 of the app-lifecycle spec, it’s mentioned :
>  
> “A typical browser-driven use case for system events is an email application that wants to show a desktop notification when a push notification is received so the user is informed that there are new emails even though the tab in which the email application was running has been closed.”
>  
> In this specific use case, would it be rather the email application that should have a background task running and responsible to keep checking for new email in the server,

Yes.

> and when it does, the email application is the one that will send request to the system to display desktop notification ?

I think it might be beneficial for the ServiceWorker to be able to create and show notifications too. 

However, we'll need a way to request permission from the user before allowing that. For example, the visible email application window could invoke requestPermission() as usual (using the Notifications API as an example here) and communicate the permission decision back to the associated ServiceWorker. Once the permission has been granted, the ServiceWorker could say new Notification() to show a notification even if there are no windows or tabs open for the email app.

The issue with permissions is a generic one, and should be addressed in a generic way. Suggestions welcome :-)

Thanks,

-Anssi

[1] https://github.com/slightlyoff/ServiceWorker/
[2] http://www.w3.org/2012/sysapps/app-lifecycle/

Received on Wednesday, 23 October 2013 20:03:24 UTC