Re: Some comments in Execution and Security Model spec

Hi Hongbo,

On Tuesday, April 16, 2013 at 2:03 PM, Min, Hongbo wrote:

> Hi, Runtime model editors,  
>  
> I just read carefully about the Runtime model spec at http://sysapps.github.io/sysapps/proposals/Sysapps-Runtime/Overview.html#runtime and put down some comments for your reference. Please educate me if I have misunderstanding. Thanks.

Thanks for the comments. Please note that that spec is out of date, but your comments are still relevant. We will be pulling down those specs this week to avoid confusion.  

The new spec is at:
http://runtime.sysapps.org/
  
>  
> 1. Application update/uninstall behavior when it is running
>  
> If an application is in running state, and at the moment RuntimeInstaller try to update/uninstall it, what should be the expected behavior?

Filed a bug to try to clarify, though the other editors may provide some guidance here…  
https://github.com/sysapps/runtime/issues/80  
  
>  
> 2. About using DOMRequest as return value
>  
> Lots of API is designed to return DOMRequest object. I think it should be better to define the meanings of DOMRequest object status, such as what onsuccess/onerror/readyState/result/onerror stands for respectively in Runtime model. For example, if the given applicationId parameter cannot be found, then what is the status of the returned DOMRequest object?

We will be removing DOMRequest from all specs in favor of Futures:
http://dom.spec.whatwg.org/#futures
  
>  
> 3. Be better to add ‘description’ field in application manifest since Application object also has a description field.

please see:
http://runtime.sysapps.org/#description-member

Is that sufficient?   
>  
> 4. About application update, is it better to support auto-update through adding a ‘update_url’ in application manifest file?

I've added this question also to:
https://github.com/sysapps/runtime/issues/80  


  
>  
> If ‘update_url’ is provided in manifest file, the Runtime will periodically sync with the ‘update_url’ server to check the latest version and compare it with the current version. If it is higher than the current version, an auto-update behavior will be performed.

Versioning information (i.e., numbers) are generally unreliable, so they can only be "different". This will need to be clarified in the spec.    
>  
> 5. RuntimeInstaller interface is a privileged API and should not be accessed by untrusted application. We should prohibit untrusted application to install other applications. I found no such information is highlighted in the spec.

Correct. I've filed a bug:
https://github.com/sysapps/runtime/issues/81
>  
> 6. About Application.size, it should be in bytes, right? We should give a clear definition in spec.

Do you mean downloadSize? It currently states:
"The attribute should return the size of the download that would be required to update the application in kilobytes, if any"

http://runtime.sysapps.org/#widl-Application-downloadSize

What do you recommend we add to make this more clear?  
>  
> 7. No method to show an application in foreground if it is hidden via hide API.

As there is currently no "hide API", I'm not sure if this is an issue. Also, please note that "system messages" can be used to foreground an application at an appropriate time. See the Web Alarms API:

http://web-alarms.sysapps.org

> 8. Unclear behavior if the same application is installed/uninstalled/updated by more than on RuntimeInstaller.
> Since each system application can access its own RuntimeInstaller via window.runtime.installer, if Foo app initiates an operation to uninstall application, while at the moment, another Bar app also initiates another operation to uninstall the same application, then the expected behavior is not defined. Should RuntimeInstaller in Bar app can also receive onUninstall event if Foo app uninstall the app successfully.

An application can only be installed once. But yes, this needs to be clarified, filed a bug using your text:
https://github.com/sysapps/runtime/issues/82

>  
> 9. Does it make sense to add ‘onupdate’ event in Application interface to let Application itself be aware of update?

Could be. What use case did you have in mind? I guess it's similar to when a new version of AppCache is available.  

Kind regards,
Marcos

Received on Tuesday, 16 April 2013 18:14:38 UTC