Adding and Removing Application Packages

This section considers adding and removing application packages to/from Repository.

Adding Application Packages

Performing adding package operation correctly is very important as it predetermines further successful package processing. Before adding a package to Repository it should be validated. The validation procedure may comprise the following steps:

Validating basic conformity. The Controller must first validate the package basing on the following criteria:
- the package file has the .app.zip extension;
- the package is successfully unzipped;
- the package contains an APP-META.xml file in its root;
- the APP-META.xml is parsed by the Metadata Parser according to the rules of basic metadata format defined by the Specification.
Recognizing a package. The most important point about adding an application package is that the Controller should accurately recognize it. The Controller actions to be performed for this purpose differ depending on APS format version the application is packaged with. So, the first step is defining APS format version. The Controller should get APS format version from the package metadata file with Metadata Parser. As defined by the Specification, this data is contained as follows:
```
<application xmlns="http://apsstandard.com/ns/1" version="1.1">
```
Note: if the version attribute is absent, the APS format version is 1.0.
- APS 1.0. Metadata Parser successfully gets the application name, version, and release from the APP-META.xml file. It is enough for the Controller to know this general information about the package. As defined by the Specification, this data is contained in the metadata file as follows:
```
  <name>phpBB</name>
```
```
  <version>2.0.22</version>
```
```
  <release>6</release>
```
- APS 1.1. Metadata Parser successfully gets the application name, version, and release from the APP-META.xml file. It is enough for the Controller to know this general information about the package. As defined by the Specification, this data is contained in the metadata file as follows:
```
  <name>phpBB</name>
```
```
  <version>2.0.22</version>
```
```
  <release>6</release>
```
- APS 1.2. This APS format version involves the following criteria to be validated by the Controller:
  - the package contains a APP-LIST.xml file in its root;
  - the APP-LIST.xml is parsed by the Metadata Parser according to the rules of contents listing format defined by the Specification;
  - Metadata Parser successfully gets list of files and their corresponding SHA256 values from the APP-LIST.xml;
  - the Controller checks that the list of package files and their current SHA256 values match those extracted from the APP-LIST.xml. This operation ensures package integrity;
  - Metadata Parser successfully gets list of package signatures, if any from the APP-LIST.xml;
  - the Controller checks signatures validity to ensure package origin;
  - Metadata Parser successfully gets the application unique identifier, the application name, version, release and master package identifier (if any) from the APP-META.xml. As defined by the Specification, this data is contained in the package metadata file APP-META.xml as follows:
```
<application xmlns="http://apsstandard.com/ns/1" version="1.2">
```
```
  <id>http://www.phpbb.com/</id>
```
```
  <name>phpBB</name>
```
```
  <version>2.0.22</version>
```
```
  <release>6</release>
```
```
  <master-package>
```
```
    <package id="http://www.phpbb.com" match="version = 1.1"/>
```
```
</master-package>
```
```
  ...
```
```
</application>
```
If the Controller gets the identifier of a master package from the package metadata, it must check whether the master package is in Repository already or not. If the master package is in Repository the Controller should somehow store the information about their master to add-on relations. Otherwise, the Controller must refuse to add the package to Repository returning the proper error message.

The unique application identifier is very important for further package processing. The Controller must ensure that this identifier is really unique for an application among others in Repository.

Note: for details on the metadata file format, refer to the 5. Metadata Descriptor section of the Specification.
Displaying validation result. If a package successfully passes validation procedure the Controller may display a success message to a user. If a package fails to pass the validation basing on any criterion above, the Controller must refuse to add the package to Repository returning the proper error message.

These criterions of package validity are not the only ones, but the ones required on the stage of adding a package to Repository so that the package then can always be uniquely identified by Controller. The other package validity criteria are defined by the Specification in the section 4. Basic Package Format.

We recommend that when adding a package to Repository, the Controller checks whether it can recognize the metadata elements defined by aspects, namely, the elements which describe application requirements, provision methods (URL handlers and/or configuration script language) and permissions. This is the best way to detect non-qualified technologies used by the application as early as possible, and to expand the Aspects Parser functionality in a good time.

Removing Application Packages

It's worth considering the implementation of removing packages from your Repository. Note that it is only a recommendation, there are no rules for removing packages defined by the Specification, so this Controller operation is at your option.

In This Section

Possible Scenario