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

> -----Original Message-----
> From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com]
> 
> Hi All,
> 
> I've updated the "Application Lifecycle and Events" draft [1] that we
> reviewed at the F2F last week as per the F2F feedback by you recorded at
> [2]. The draft is now annotated with many NOTEs (non-normative) and ISSUEs
> (normative implications) that map directly to your feedback.
>

Thanks Anssi. I think this is a good starting point to sort them out.


> All the comments in the Etherpad document [2] marked as [CLOSED] should
> have a corresponding commit at [3]. The comments marked as [OPEN] require
> more information or clarification.
> 

As I went through, we have 6 [OPEN] issues left:
1. It seems that this spec addresses two different use cases: a "service"
with no UI (pure js) and an "application" with UI on/off capability.  I'm
not sure about  the "application" use case, we would need compelling
concrete use cases for it.  Anyway, it would help readers if we clarify this
at first.
[OPEN] Needs clarification.

[jungkees] The mission of the group is stated in the charter [4] as "to
define a runtime environment, security model, and associated APIs for
building Web applications with comparable capabilities to native
applications." Regarding the "background service" and "foreground app", we
have quite a few related issues and notes in section "4.1 A Single Entry
Point to the Application" and section "5. Main Document". I suggest we close
this item.


2. Is there any strong reason that the apps should be enforced to have
single entry point?  Single entry point break some WEB features potentially.
For example, we can not link to specific content provided by an app
directly.  It can be just a choose of developers themself.
[OPEN] Need to understand which features will be broken, clarify "link to
specific content".

[jungkees] Again the main reason simply comes from the fact that we aim to
deliver the native application user experience to the open web. However, I
totally agree that the core design of the runtime model should be able to
embrace the advantages of the existing web architecture.


3. Add more examples to make sure developer ergonomics issues are addressed.
[OPEN] Need to agree on a set of examples.


4. "runtime" is wierd! "app" maybe?
[OPEN] This is a topic for bikeshedding about naming :-)

[jungkees] +1. seems like a bikeshedding issue. :-)


5. Giri: Certain types of events should be handled with highest priority
when the application is in post-launch mode.  For instance, a foregrounded
application that has an open 1X-EV-DO data session receive a voice page
interrupt.  If the app has a handler designated for this event, it should
take highest priority.  Should the document mention that certain persistent
events must be handled by the runtime differently from other types of
persistent events, or can we leave it up to the implementation?
[OPEN] Wouldn't every app want to have its events handled at highest
priority? IIRC this issue was raised in Web Notifications WG too, and never
implemented due to this reason. How is this different?

[jungkees] I believe it will not be easy to explictly set the priorities of
the persistent events in this spec. I presume the priorities to be depending
on specific implementations; also, we might need extended persistent event
definitions in future use cases, which potentially breaks backward
compatibility?


6. "main": { "source": "main.html", "type": "html" }
"main": { "source": "main.js", "type": "worker" }
mounir: if we do that, we could as well remove the type.
so if people use main.xhtml? or main.js type: html?
[OPEN] Needs to be defined in the Web Manifest spec

[jungkees] Chrome's manifest is doing:
{ "background": { "scripts": ["background.js"] } }
{ "background": { "page": "background.html" } }

The current draft is doing:
{ "main": { "scripts": ["polymer.min.js", "main.js"] } }
{ "main": { "source": "main.html" } }

I think we'd better discuss this topic in line with the _main document_
architecture - worker global vs document global and whether this environment
should be allowed to be non-persistent like Chrome's event page; it seems
the manifest definition for this part would be closely related.



> The most significant changes were (for a detailed changelog see [3]):
> 
> * Added NOTEs and ISSUEs as per your review comments.
> 
> * Clearer split between non-normative sections (use cases etc.) and
> normative sections. All the sections that are non-normative now start with
> the usual "This section is non-normative" for clarity. Also RFC 2119 terms
> are only used in normative sections of the document now. [Special thanks
> to Marcos for the most entertaining conformance class comment :-)]
> 
> * Added a strawman proposal for "a dualistic main document" that can be of
> type document or worker. I think we may want to try to pick one type for
> v1 to allow us move faster.
> 
> All - if you have a preference for either a document or worker-derived
> main document/event page we'd like to hear from you now.
> 
> Lastly, I think we may want to merge this draft into sysapps runtime repo
> soon to make it easier for people to start contributing, including our new
> co-editors Marcos and Jungkee ;-)
> 

+1. Good idea! :-)


> Thank You All for the most productive F2F session, feedback and comments.
> 
> -Anssi
> 
> [1] http://anssiko.github.io/runtime/app-lifecycle.html
> [2] https://etherpad.mozilla.org/event-pages
> [3] https://github.com/anssiko/runtime/commits/lifecycle
[4] http://www.w3.org/2012/09/sysapps-wg-charter.html#title

Received on Monday, 9 September 2013 14:53:20 UTC