Hi all,As we are pushing forward our implementation of runtime model and extension APIs, it's becoming increasingly important and urgent for us to finalize the category of API permissions requirements, on which many other features are dependent, like manifest, security architecture, API itself, and so forth. So let me first introduce a little bit about it in case some of you may not very familiar with. This http://developer.chrome.com/apps/manifest.html is the chromium manifest definition. There are two regions regarding the issue in question:
"permissions <http://developer.chrome.com/apps/declare_permissions.html>": [...], "requirements <http://developer.chrome.com/apps/manifest/requirements.html>": {...},The permissions is the field an application must declare in its manifest in order to use the corresponding API. For example "alarms" for chrome.alarms API. The requirements denotes the technologies required by the application, it may looks like this
"requirements": {
"3D": {
"features": ["webgl"]
}
}
In Tizen we also have these permissions and requirements defined,
in a similar way. For example the privilege
"http://tizen.org/privilege/alarm"; maps to the Alarm APIs (
add,remove,etc..) You may refer to the attachment for more details.
So as you are all aware, we've got a lot of APIs to implement, some
of which comes from tizen and some from w3c, and we also have a road map
for that. The issue is, we need a way to categorize these APIs into
different permission/requirement groups, just like that in Tizen or
chromium. It might be a little hard for us because we may need to align
with W3c or Tizen.
How do you think?
--
- Ming, Bai
Privilege for Device APIs.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
