Plugins/de

Revision as of 11:25, 13 April 2018

Überblick

OpenSimulator verwendet verschiedene Mechanismen, um die dynamische Konfiguration von Funktionen zu ermöglichen. Diese Seite beschreibt diese Mechanismen.

Dynamische Plugins mit Mono.Addins

Einige Plugins werden zur Laufzeit mit Extension Points erkannt und mit Mono.Addins geladen. Dieser Mechanismus wird hier und hier detailliert beschrieben.

Diese Arten von Plugins werden verwendet, wenn es wünschenswert ist, alle Plugins eines bestimmten Typs zu laden.

Dieser Mechanismus wird derzeit in den folgenden Fällen verwendet:

/OpenSim/Startup - Anwendung Plugins (IApplicationPlugin). Wird von OpenSimBase geladen, wenn OpenSimulator gestartet wird. Die Plugins werden mit PluginLoader geladen.

/OpenSim/RegionModules - Region-Module. Geladen von RegionModulesControllerPlugin, welches selbst ein Anwendungs-Plugin ist. Die Plugins werden durch direkten Aufruf von AddinManager geladen (nicht über PluginLoader).

/OpenSim/WindModule - Windmodelle . Geladen von WindModule, welches selbst ein Regionalmodul ist. Die Plugins werden durch direkten Aufruf von AddinManager geladen.

Unused Extension Points

There are some extension points defined that are never actually loaded. For example, OpenSim.data.MySQL.addin.xml defines plugins that provide implementations for extension points such as "/OpenSim/GridData" and "/OpenSim/AssetData". However, no-one actually loads these extension points (as far as I can see). Instead, these plugins are loaded using the config-files technique described below.

These points have been removed in OpenSimulator code after 0.7.1.1.

Specifying Plugin Implementation in the Configuration

For most plugins, the class that should be used to implement the plugin's interface is specified explicitly in one of the .INI files. The application then simply loads the assembly (DLL); finds the specified class; and instantiates it.

These types of plugins are used when it only makes sense to load a single implementation of the plugin; not all the available implementations. For example, only one database access module can be used. Therefore, the .INI files contain directives such as these:

[DatabaseService]
   StorageProvider = "OpenSim.Data.MySQL.dll"

Sometimes the definition also specifies which class to use. For example:

[InventoryService]
   LocalServiceModule = "OpenSim.Services.InventoryService.dll:XInventoryService"

Let's take the example of the data-access plugin further. Most classes that need to access the database have a Data interface defined. For example, PresenseService defines IPresenceData. This interface has implementations for all of the databases OpenSimulator supports. When the service starts, it loads the database assembly that was specified in the configuration, and then finds in that assembly the class that implements the desired interface (IPresenceData). The code looks something like this (although this is simplified):

IConfig dbConfig = config.Configs["DatabaseService"];
string dllName = dbConfig.GetString("StorageProvider");
IPresenceData m_Database = LoadPlugin<IPresenceData>(dllName);

Connectors

Robust finds and loads its Connectors by having them specified explicitly in Robust.ini (in the "ServiceConnectors" entry). Since the plugins are specified explicitly, this works by loading the DLL's manually. However, it's somewhat similar to the Mono.Addins technique in that Robust loads all the connectors specified; not just one. Perhaps it can be refactored someday to truly use Mono.Addins.

The connectors are loaded by calling ServerUtils.LoadPlugin<IServiceConnector>().