Application Extension Bundle (AEB)

An application extension bundle (AEB) encapsulates all the data required to extend an application. Often refered to as a plug-in or add-on, an AEB is a specific format designed to be application and platform agnostic. AEB defines common file formats and directory layouts. Extension and specification points are defined by a target application.

The AEB format is based on the XPI format used by the Mozilla XPInstall addon system. XPI is a compelling format containing much of the metadata and encapsulation information needed for an AEB. However, the XPI format is tightly coupled to the Mozilla project and the description documents often refer to specific XPI engine implementation details. AEB standardizes XPI and removes the Mozilla specific details. The original version of AEB is nearly an exact copy of the XPI format with minor changes and clarifications. AEB should, however, be considered a fork of XPI and further changes to XPI may not be reflected in AEB.

An AEB is a ZIP archive containing AEB specific files and target application files. The AEB specific files within the ZIP must use commonly compatible ZIP options. Since ZIP is a defacto standard, the features which are commonly compatible are not explicitly stated here but can be determined by a survey of available ZIP libraries. The version of the published ZIP specification at the time this document was written is 6.3.2. Optional compression algorithms and ZIP file extensions may be supported by a target application for target application specific files. An AEB may also exist as a directory hierarchy on a file system or file system-like service. (such as an FTP site) This is intended for use while devoloping an AEB. An AEB should be deployed as a ZIP archive. The file extension of an AEB ZIP archive must be .aeb unless a particular system does not support file extensions. When an AEB is associated with a MIME type (such as when served by an HTTP server) the MIME type should be application/x-aeb. The MIME type may be application/zip or application/octet-stream. A target application may impose additional file extension and MIME type restrictions. (for example, .myapp.app and application/x-aeb+x-myapp) A target application imposing additional restrictions may only require those restrictions on AEBs targetting only the target application. An AEB with multiple target applications must use only the restrictions in this document. A target application should always accept files meeting only the restrictions in this document.

Every AEB must contain an install manifest in /install.rdf. This file contains a AEB metadata written in the application extension bundle description language (AEBL). This file shall be serialized in RDF+XML format. The root directory may also contain the following directories.

This contains most of the AEBs extension files. The contents of this directory are specific to a target application but generally contain files which will be installed in the target application.

The /platform directory may contain sub-directories for each platform declared in the install.rdf file. The contents of the sub-directory corresponding to the current platform are unioned with the /content directory. If both directories contain a specific file, the /platform directory takes precedence. Not all platforms declared in the install.rdf file require a /platform directory.

This directory generally contains icon files referenced in the install.rdf file. These should not be installed by the target application.

This directory generally contains license files referenced in the install.rdf file. There should not be installed by the target application.

An AEB may contain multiple AEB archives if the multiple item AEB type is specified in the install.rdf file. The /content and /platform directories should contain only files with the .aeb extension. These must be AEB ZIP archives. AEB archives in the /content directory shall be installed on all platforms and AEB archives in a sub-directory of /platform shall be installed on that platform. The installation order may be arbitrary but a target application may define a specific order. Failure to install any AEB archive in a multiple item AEB shall result in failure to install the entire multiple item AEB.

Installation of an AEB shall be an atomic operation. Failure to install an AEB shall remove a partially installed AEB.

If an AEB request installation of a resource which is already present in the target application, the resource should be reference counted. When an AEB with a shared resource (a resource with a reference count greater than one) should only remove the resource if decrementing the reference count yields a new reference count of zero.