Re: Request to make one proposal for execution model and security model

On 19/02/13 08:47, Jungkee Song wrote:
>> -----Original Message-----
>> From: Mounir Lamouri [mailto:mounir@lamouri.fr]
>> Sent: Saturday, February 16, 2013 9:16 AM
>>
>> On 13/02/13 14:08, Wonsuk Lee wrote:
>>> Hi. Jungkee, Mounir, Jonas and all.
>>>
>>> Jungkee, thanks a lot for your proposal.
>>>
>>> Mounir and Jonas, for going forward, the WG have to get your
>>> feedback!! I hope to get your opinions soon.
>>
>> Hi,
>>
>> Again, sorry for taking so long to reply to this.
>>
>> I do not thing that merging the two documents is the best way to go. I
>> think we will inevitably end up in contradictory terms and definitions and
>> it would take a long time to unify the merged document. For example, you
>> can see that the merged document mentioned "hosted applications",
>> "packaged applications" and "system applications" depending on whether the
>> block was originally written in the Mozilla's proposal or the Samsung's
>> one.
>>
>> I believe that the best way to start is to keep one document and expand it.
>> That way, we can keep a consistent document and make sure that the feature
>> set matches everyone's needs. Given that the features covered by the
>> documents are not dramatically different, this shouldn't be a too hard
>> process.
>>
> 
> It's not the case that the three terms have been unintentionally intermingled. As explained in the previous post, we had intended to use system application as a term to represent the installed web applications including both hosted apps and packaged apps. Indeed, the terms and definitions are topics we have to sort out during the discussion anyway.
> 
> 
>> The current document from Mozilla defines an API for a web application to
>> become a store, it defines what is a hosted applications and how an
>> application can be self-hosted. We care particularly about those parts of
>> our specification and we think that this is the angular stone of a
>> successful web applications ecosystem. Those concepts are missing from the
>> Samsung document and merged proposal. We also specify the System Message
>> mechanism that we believe is important to make events working for
>> installed web applications. Typically, it solves issues that the service
>> request with the request event would run into (we can get into details
>> later).
>>
>> However, the document from Samsung has a better Execution model than the
>> Mozilla proposal.
>>
> 
> We believe that one of the essential points of the standardization of this spec is to cover common aspects of Chrome, Firefox OS, Tizen, Webinos and other Web platforms. In that, the description of execution model would be crucial. We would like to take the following topics into account:
> 
>   * Execution Lifecycle (States and Events) *
>   1) What are the possible execution states a web app could have?
>   2) What events should be fired upon the state transition?

We have included your work to our specification.

>   3) Any additional system events required? (such as language change, low memory, etc.)

I think those are very interesting points. We are currently working an a
language change event. I do not think we have a low memory event. Our
current behaviour is to simply kill applications in background if there
is no memory. I guess this assumes that the applications will save
everything when paused.

>   * Browsing Context Management *
>   1) Should runtime allow multiple windows opened concurrently?
>     1-a) How to manage them (from UI perspective)?

I think we need implementations feedback for that. Is Tizen and Webinos
only allow to see one application at a time? Firefox OS only shows one
application at a time (except some very specific cases) and only shows
one application window at a time. Like Android would do.

>     1-b) Do all of them receive lifecycle events or only the main browsing context?

Why not only the Application object?

>   2) Should runtime allow browsing context navigation? (e.g., window.location)

Our current plan is to say no by default but allow the application to
opt-in (see "7. Navigation"). The reason is that users might be stuck
out of the application if they navigate away from it. Making this
explicit makes sure the developers knows what he/she is doing.

>   3) Inter-app communication (Web Activity or Web Intents) behavior in runtime environment
>     3-a) Caller / callee view stack management
>     3-b) Caller / callee lifecycle states and events

I think that should live in a separate specification.

>   * Runtime Security *
>   CSP Policy resolution from different sources (http header, manifest, runtime default), Cross Origin Relaxation, etc.

That's definitely in scope.

>   * Advanced Execution Model * for next version
>   Execution model for background service page (which is covered only by Google strawman proposal)

We haven't figure that out yet at Mozilla. Any feedback from Webinos or
Tizen would be interesting.

--
Mounir

Received on Tuesday, 19 February 2013 18:01:02 UTC