diff options
| -rw-r--r-- | docs/1-afm-daemons.md | 62 | ||||
| -rw-r--r-- | docs/2.1-widgets.md | 5 | ||||
| -rw-r--r-- | docs/2.2-config.xml.md | 20 | ||||
| -rw-r--r-- | docs/3-permissions.md | 4 | ||||
| -rw-r--r-- | docs/4-quick-tutorial.md | 2 | ||||
| -rw-r--r-- | docs/5-frameworks.md | 34 | ||||
| -rw-r--r-- | docs/5.1-application-framework.md | 37 |
7 files changed, 79 insertions, 85 deletions
diff --git a/docs/1-afm-daemons.md b/docs/1-afm-daemons.md index 6d31e34..ec7307b 100644 --- a/docs/1-afm-daemons.md +++ b/docs/1-afm-daemons.md @@ -30,7 +30,7 @@ depending upon ***D-Bus*** destination. The figure below summarizes the situation of both **afm-system-daemon** and **afm-user-daemon** in the system. -![afm-daemons][afm-daemons] +![afm-daemons][afm-daemons]{style width:65%;} The D-Bus interface ------------------- @@ -198,7 +198,7 @@ the fields described below. "id": string, the application id (id@version) "version": string, the version of the application "width": integer, requested width of the application - "height": integer, resqueted height of the application + "height": integer, requested height of the application "name": string, the name of the application "description": string, the description of the application "shortname": string, the short name of the application @@ -388,7 +388,7 @@ Use **org.AGL.afm.user.resume** instead. #### Method org.AGL.afm.user.state -**Description**: Get informations about a running instance of *runid*. +**Description**: Get information about a running instance of *runid*. **Input**: The *runid* (integer) of the running instance inspected. @@ -431,49 +431,49 @@ The options for launching **afm-system-daemon** are: -r --root directory - + Set the root application directory. Note that the default root directory is defined to be /usr/share/afm/applications (may change). - + -d --daemon - - Daemonizes the process. It is not needed by sytemd. - + + Daemonizes the process. It is not needed by systemd. + -q --quiet - + Reduces the verbosity (can be repeated). - + -v --verbose - + Increases the verbosity (can be repeated). - + -h --help - + Prints a short help. - + ### ***afm-user-daemon*** options The options for launching **afm-user-daemon** are: -a --application directory - + [Currently not available in the systemd version] Includes the given application directory to the database base of applications. - + Can be repeated. - + -r --root directory - + [Currently not available in the systemd version] Includes root application directory or directories when @@ -483,33 +483,33 @@ The options for launching **afm-user-daemon** are: Note that default root directory for applications is always added. In current version /usr/share/afm/applications is used as default. - + -m --mode (local|remote) - + [Currently not available in the systemd version] Set the default launch mode. The default value is 'local' - + -d --daemon - - Daemonizes the process. It is not needed by sytemd. - + + Daemonizes the process. It is not needed by systemd. + -q --quiet - + Reduces the verbosity (can be repeated). - + -v --verbose - + Increases the verbosity (can be repeated). - + -h --help - + Prints a short help. Tasks of **afm-user-daemon** @@ -518,7 +518,7 @@ Tasks of **afm-user-daemon** ### Maintaining list of applications At start **afm-user-daemon** scans the directories containing -applications and load in memory a list of avaliable applications +applications and load in memory a list of available applications accessible by current user. When **afm-system-daemon** installs or removes an application. @@ -528,7 +528,7 @@ applications list. **afm-user-daemon** provides the data it collects about applications to its clients. Clients may either request the full list -of avaliable applications or a more specific information about a +of available applications or a more specific information about a given application. ### Launching application diff --git a/docs/2.1-widgets.md b/docs/2.1-widgets.md index 93cd788..fa571e1 100644 --- a/docs/2.1-widgets.md +++ b/docs/2.1-widgets.md @@ -125,15 +125,12 @@ This allows every user to read every file. ### labeling the directories of applications -The data of a user are in its directory and are labelled by the security-manager -using the labels of the application. +The data of a user are in its directory and are labelled by the security-manager using the application labels. [widgets]: http://www.w3.org/TR/widgets "Packaged Web Apps" [widgets-digsig]: http://www.w3.org/TR/widgets-digsig "XML Digital Signatures for Widgets" -[libxml2]: http://xmlsoft.org/html/index.html "libxml2" [app-manifest]: http://www.w3.org/TR/appmanifest "Web App Manifest" - [meta-intel]: https://github.com/01org/meta-intel-iot-security "A collection of layers providing security technologies" [widgets]: http://www.w3.org/TR/widgets "Packaged Web Apps" [widgets-digsig]: http://www.w3.org/TR/widgets-digsig "XML Digital Signatures for Widgets" diff --git a/docs/2.2-config.xml.md b/docs/2.2-config.xml.md index cccedd4..87d139f 100644 --- a/docs/2.2-config.xml.md +++ b/docs/2.2-config.xml.md @@ -75,13 +75,13 @@ arabic digits, and the three characters '.' (dot), '-' (dash) and '\_' (underscore). Version values are dot separated fields MAJOR.MINOR.REVISION. -Such version would preferabily follow guidelines of -[semantic versionning][semantic-version]. +Such version would preferably follow guidelines of +[semantic versioning][semantic-version]. ### The element content The element *content* is mandatory (for version 2.x, blowfish) and must designate a file -(subject to localisation) with its attribute *src*. +(subject to localization) with its attribute *src*. The content designed depends on its type. See below for the known types. @@ -104,7 +104,7 @@ the features are of important use to: - declare the expected permissions - declare the exported apis -The specification of [widgets][widgets] is intentded to describe +The specification of [widgets][widgets] is intended to describe only one application. In the present case, we expect to describe more than just an application. For example, a publisher could provide a widget containing a service, an application for tuning @@ -177,7 +177,7 @@ It is either: - link: - The framework connect in memory by dinamically linking + The framework connect in memory by dynamically linking - cloud: [PROPOSAL - NOT IMPLEMENTED] @@ -407,7 +407,7 @@ files corresponding to the need and requirements of the installed widgets. This configuration file named `afm-unit.conf` installed -on the system wiht the path `/etc/afm/afm-unit.conf` +on the system with the path `/etc/afm/afm-unit.conf` describes how to generate all units from the *config.xml* configuration files of widgets. The description uses an extended version of the templating formalism of [mustache][] @@ -427,15 +427,15 @@ representation is shown along the examples of the documentation of the config files of widgets. In a second step, the mustache template `afm-unit.conf` -is instanciated using the C library [mustach][] that follows +is instantiated using the C library [mustach][] that follows the rules of [mustache][mustache] and with all its available extensions: - use of colon (:) for explicit substitution - test of values with = or =! -In a third step, the result of instanciating `afm-unit.conf` -for the widget is splited in units. To achieve that goal, +In a third step, the result of instantiating `afm-unit.conf` +for the widget is split in units. To achieve that goal, the lines containing specific directives are searched. Any directive occupy one full line. The directives are: @@ -501,7 +501,7 @@ record the allocated port for applications. [app-manifest]: http://www.w3.org/TR/appmanifest "Web App Manifest" [tizen-security]: https://wiki.tizen.org/wiki/Security "Tizen security home page" [tizen-secu-3]: https://wiki.tizen.org/wiki/Security/Tizen_3.X_Overview "Tizen 3 security overview" -[semantic-version]: http://semver.org/ "Semantic versionning" +[semantic-version]: http://semver.org/ "Semantic versioning" diff --git a/docs/3-permissions.md b/docs/3-permissions.md index 0c18180..480bfef 100644 --- a/docs/3-permissions.md +++ b/docs/3-permissions.md @@ -80,14 +80,14 @@ Conversely, permissions linked to cynara can't carry data except in their name. Thus to have a simple and cleaner model, it is better to forbid -attachement of value to permission. +attachment of value to permission. Example of permissions ---------------------- Here is a list of some possible permissions. These -permissions are available the 17th of March 2017. +permissions are available the 17th of March 2017. - urn:AGL:permission::platform:no-oom diff --git a/docs/4-quick-tutorial.md b/docs/4-quick-tutorial.md index c8122d4..2ed7cf9 100644 --- a/docs/4-quick-tutorial.md +++ b/docs/4-quick-tutorial.md @@ -48,7 +48,7 @@ Connect through SSH on the target board and check for Application Framework daem We can see that there are two daemons running: * **afm-system-daemon** runs with a system user 'afm' and is responsible for installing/uninstalling packages -* **afm-user-daemon** runs as a user daemon (currently as root because it's the only real user on the target board) and is responsible for the whole lifecycle of the applications running inside the user session. +* **afm-user-daemon** runs as a user daemon (currently as root because it's the only real user on the target board) and is responsible for the whole life cycle of the applications running inside the user session. The application framework has a tool running on the Command Line Interface (CLI). Using the **afm-util** command, you can install, uninstall, list, run, pause ... applications. diff --git a/docs/5-frameworks.md b/docs/5-frameworks.md index e69de29..fb73ff2 100644 --- a/docs/5-frameworks.md +++ b/docs/5-frameworks.md @@ -0,0 +1,34 @@ +Application framework +===================== + +Foreword +-------- + +This document describes application framework fundamentals. +FCS (Fully Conform to Specification) implementation is still under development. +It may happen that current implementation somehow diverges with specifications. + +Overview +-------- + +The application framework on top of the security framework +provides components to install and uninstall applications +as well as to run them in a secured environment. + +The goal of the framework is to manage applications and hide security details +to applications. + +For the reasons explained in introduction, it was choose not to reuse Tizen +application framework directly, but to rework a new framework inspired from Tizen. + +fundamentals remain identical: the applications are distributed +in a digitally signed container that should match widget specifications +normalized by the W3C. This is described by the technical +recommendations [Packaged Web Apps (Widgets)](http://www.w3.org/TR/widgets) and [XML Digital Signatures for Widgets](http://www.w3.org/TR/widgets-digsig) of the W3 consortium. + +As today this model allows the distribution of HTML, QML and binary applications +but it could be extended to any other class of applications. + +The management of widget package signatures. +Current model is only an initial step, it might be extended in the +future to include new feature (ie: incremental delivery). diff --git a/docs/5.1-application-framework.md b/docs/5.1-application-framework.md index 0b9750d..942ff9c 100644 --- a/docs/5.1-application-framework.md +++ b/docs/5.1-application-framework.md @@ -1,40 +1,3 @@ - -Application framework -===================== - -Foreword --------- - -This document describes application framework fundamentals. -FCS (Fully Conform to Specification) implementation is still under development. -It may happen that current implementation somehow diverges with specifications. - -Overview --------- - -The application framework on top of the security framework -provides components to install and uninstall applications -as well as to run them in a secured environment. - -The goal of the framework is to manage applications and hide security details -to applications. - -For the reasons explained in introduction, it was choose not to reuse Tizen -application framework directly, but to rework a new framework inspired from Tizen. - -fundamentals remain identical: the applications are distributed -in a digitally signed container that should match widget specifications -normalized by the W3C. This is described by the technical -recommendations [widgets] and [widgets-digsig] of the W3 consortium. - -As today this model allows the distribution of HTML, QML and binary applications -but it could be extended to any other class of applications. - -The management of widget package signatures. -Current model is only an initial step, it might be extended in the -future to include new feature (ie: incremental delivery). - - Comparison to other frameworks ------------------------------ |