Platform Specification

Introduction

Plugins

Plugin Life cycle

Once the plugin has been loaded, it can be in one of the following states:

• STATE_UNINSTALLED
• STATE_INSTALLED
• STATE_ACTIVE
• STATE_DEACTIVATED
• STATE_DISPOSED

Refer to the following state diagram for an overview of the full lifecycle of a Plugin:

Initial state

Each plugin starts with a creation of PluginContainer. A PluginContainer is a container and a wrapper around a Plugin and it is a primary representation of a plugin in the Platform.

A PluginContainer holds references to the PluginResource (an abstraction for easy access to the plugin bundled resources), to the plugin hook objects (as exposed by the Plugin Manifest), and to a list of the exports and dependencies for this plugin (as exposed by the Plugin Manifest).

Once a PluginResource is created, and thus the initial structure of the plugin bundle has been confirmed to be valid, a Plugin will be put in the STATE_UNINSTALLED state.

Resources

Resource Loader object protocol:

class ResourceLoader:

    def load(self, str_rc_id_specs, *args, **kwargs):
       # perform the lookup and load here

Resource ID String Specification

The resource ID string specification is as follows:

[[<protocol>:]...]<resource_id>

where:

• protocol - protocol which determines the means of accessing the resource (e.g. file, plugin, class etc)
• resource_id - the actual resource ID. In the context of the access mechanism (protocol handler), this may be: the file path, the name of the plugin, the full class name, etc

Examples of Resource ID Strings

• plugin:core-event-loop
• file:conf/platform.ini
• class:nanopp.platform.Platform
• singleton-object
• bca87585-18bd-440f-87a9-7cc44e56a639

or, some complex ones:

• plugin:tar.gz:my-plugin-2.3
• plugin:zip:ui-plugin.zip
• file:zip:archive.zip/someFile.txt

Protocols and protocol handlers

Protocol Hanlders

Supported protocols

Storage

Service Locator

Platform API