RE: [Execution and Security Model] Proposal from Samsung Electronics

Hi Mounir,

Thanks for the reply. I hope we can speed up from this point on. :-)
Here I  tried to answer your questions. Regarding the merge activity, let me respond to the separate thread very soon.

> -----Original Message-----
> From: Mounir Lamouri [mailto:mounir@lamouri.fr]
> Sent: Saturday, February 16, 2013 3:36 AM
> 
> * Application service *
> 
> I think mentioning this is confusing. It is better to let the
> specification (Web Intents, Web Activities or whatever the name happen to
> be) that will handle that simply plug itself to the manifest format.
> 

Agreed. Our intention was to mention the requirement to support our execution model which should also cover the inter-app communication mechanism. We used application service mechanism which is very similar to Web Intents or Web Activities while the standardization of latter is more or less pending.

> * System Applications *
> 
> It is not very clear if this specification takes care of the hosted
> applications and packaged applications or only the later. There is a clear
> mention of the ability to install an application without a package but
> every thing seems to be written with a package in mind. Or maybe I'm
> biased because my vision of the non-packaged application is different from
> the vision this specification has.

Yes, we intended to take both of them into account.

> Also, the name of "system application" is a bit confusing [to me]. I think
> the name of "hosted applications" and "packaged applications" as chosen by
> Mozilla [1] and Google [2][3] is better. This said, Mozilla uses "web
> application" as a generic name and we should probably call those
> "installed web applications".
> 

In our proposal, system application is a generic term to represent both hosted applications and packaged applications; i.e. installed Web applications. I think there's no doubt in that both proposals dealt with both hosted and packaged apps in their scope. Regarding the term, if system application is not clear, I agree to use "installed Web applications" if everyone's happy. "Web application" tends to be more or less too generic, meaning server side implementation as well.


> * Update *
> 
> I do not think we should make the version meaningful. It is way too hard
> to have good heuristics for version numbers and if we don't use heuristics,
> apps might break because they will not follow the convention of the
> specifications. In addition, the web doesn't have any concept of version
> and we should just follow that trend and keep "version" as informational.
> 
> * Runtime interface *
> 
> Adding 'name', 'version', 'platform' and 'application' directly to the
> Window object seems a bit optimistic. Given that those attributes will be
> in the global scope, it is very likely that they will end up conflicting
> with something else at some point.
> Also, it is not clear why we need 'name', 'version' and 'platform'. This
> is information the navigator object should already have.
> 

In fact, those are the attributes defined in the Runtime interface. There would not be any namespace conflict (e.g. window.runtime.name). We think the Runtime interface certainly identify the runtime itself and can come in handy when cross checking the runtime implementation details for testing purpose while WG moves the spec toward REC.


> * Application interface *
> 
> I think this is very similar to our Application interface. There are a few
> differences. For example, you guys added an id while we consider the
> 'manifestURL' to be the unique identifier of the application.
> Why do you happen to need an explicit id?
> 

I think the major difference lie in the fact that our Application interface is designed to be notified the lifecycle events and system defined events which is covered by system message in Mozilla's proposal.


> Also, .show and exit() could be replaced by already existing API in the
> Web: window.close() (for .exit()) and document.hidden (for .show).
> 

FWIW, window.close() will not work for main browsing context. That is, UA (runtime in SysApps context) initiated windows cannot be closed with window.close(). Also, window.close() does not trigger firing terminate event. When an application consists of multiple browsing contexts, document.hidden may not represent the entire application state.


> * Origin *
> 
> We have a very similar approach regarding origin in our proposal but only
> for packaged applications. We consider that hosted applications should
> simply use the origin of their manifest.
> 

Agreed except that we think the uri scheme format needs to be specified clearly. 


> * Execution Model *
> 
> This is an interesting part because it is not much considered in our
> specification. The only mention we have is that an application MAY be put
> in a paused state when not showing.
> 
> As "ISSUE 2" pointed out, I am not sure that there is a real world usage
> for a "launch" event. In addition, it is very hard to define a DOM event
> that has to be sent before load or DOMContentLoaded events because that
> mean that the handler has to be set before the event being fired but
> technically the event could be fired at any moment... This is the main
> reason why we created System Mesages. Note that if we really need to, we
> can create a "start" System Message.
> 
> The purpose of the "request" event isn't clear to me either. What are the
> use cases?
> 

"request" represents an event for inter-app communication.


> Regarding 'terminate', I wonder how much we can try to use existing events
> like 'unload'.
> 

In mobile scenario, onterminate can be a point of saving data when users abruptly terminate the application in task manager, etc.


> For 'pause'/'resume', I think this is a wide discussion because we need to
> define if it is possible to put an application in pause at arbitrary times
> (if possible at all). I don't have a strong opinion yet on the subject.
> That is why I put in our spec that this MAY be possible. For the moment
> Firefox OS doesn't do that but I think the expected behaviour should be
> specified because applications will need to know if they can be paused and
> in which situations.
> 

While playing a game, an incoming call puts the game app in paused state. After the call ends, the game may restore the game state in onresume event handler. While page visibility event is a page level event, pause/resume are designed to be working in application level.


> * RuntimeExecutionManager interface *
> 
> What exactly is expected to use this interface? I feel like this is
> something more on the system side. For example, I do not really expect any
> application to be able to call .pause() or .resume() but I would expect
> the user agent to handle that.
> 

The APIs are required for task manager-like applications. As mentioned above, platform may need to manage multiple applications.


> * Security model *
> 
> The fact that you guys have three levels of security instead of two is
> interesting. What use cases did you had in mind?
> (Actually, we also have three levels of security but the third one is more
> or less a "chrome-only" level which is mostly to not allow access to
> something so it's more an implementation detail.)
> 

In our proposal, for example, unsigned side-loaded apps could be untrusted applications; signed packaged apps downloaded from app store could be trusted applications; pre-loaded apps from OEM or operators could be privileged applications.


> [1]
> http://mounirlamouri.github.com/sysapps/proposals/RunTime-
> Security/Overview.html
> [2] https://developers.google.com/chrome/apps/docs/developers_guide
> [3] https://developer.chrome.com/extensions/apps.html
> 
> Cheers,
> --
> Mounir

Received on Monday, 18 February 2013 13:12:09 UTC