Plugins/de
From OpenSimulator
(→Unused Extension Points) |
(→Specifying Plugin Implementation in the Configuration) |
||
| Line 24: | Line 24: | ||
Diese Punkte wurden nach 0.7.1.1 im OpenSimulator-Code entfernt. | Diese Punkte wurden nach 0.7.1.1 im OpenSimulator-Code entfernt. | ||
| − | == | + | == Angeben der Plugin-Implementierung in der Konfiguration == |
| − | + | Bei den meisten Plugins wird die Klasse, die zur Implementierung der Plugin-Schnittstelle verwendet werden soll, explizit in einer der INI-Dateien angegeben. Die Anwendung lädt dann einfach die Assembly (DLL); findet die angegebene Klasse; und instanziiert es. | |
| − | + | Diese Plugins werden verwendet, wenn es nur sinnvoll ist, eine einzige Implementierung des Plugins zu laden; nicht alle verfügbaren Implementierungen. Zum Beispiel kann nur ein Datenbankzugriffsmodul verwendet werden. Daher enthalten die INI-Dateien Anweisungen wie diese: | |
[DatabaseService] | [DatabaseService] | ||
StorageProvider = "OpenSim.Data.MySQL.dll" | StorageProvider = "OpenSim.Data.MySQL.dll" | ||
| − | + | Manchmal gibt die Definition auch an, welche Klasse verwendet werden soll. Beispielsweise: | |
[InventoryService] | [InventoryService] | ||
| Line 39: | Line 39: | ||
| − | + | Nehmen wir das Beispiel des Datenzugriffs-Plugins weiter. Für die meisten Klassen, die auf die Datenbank zugreifen müssen, ist eine Datenschnittstelle definiert. Zum Beispiel definiert PresenseService IPresenceData. Diese Schnittstelle verfügt über Implementierungen für alle Datenbanken, die OpenSimulator unterstützt. Wenn der Dienst gestartet wird, lädt er die Datenbankassembly, die in der Konfiguration angegeben wurde, und sucht dann in dieser Assembly die Klasse, die die gewünschte Schnittstelle implementiert (IPresenceData). Der Code sieht ungefähr so aus (obwohl dies vereinfacht ist): | |
IConfig dbConfig = config.Configs["DatabaseService"]; | IConfig dbConfig = config.Configs["DatabaseService"]; | ||
Revision as of 11:30, 13 April 2018
Contents |
Ü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.
Unbenutzte Erweiterungspunkte
Es sind einige Erweiterungspunkte definiert, die niemals tatsächlich geladen werden. Zum Beispiel definiert OpenSim.data.MySQL.addin.xml Plugins, die Implementierungen für Erweiterungspunkte wie "/OpenSim/GridData" und "/OpenSim/AssetData" bereitstellen. Allerdings lädt tatsächlich niemand diese Erweiterungspunkte (soweit ich sehen kann). Stattdessen werden diese Plugins mit der unten beschriebenen Config-Files-Methode geladen.
Diese Punkte wurden nach 0.7.1.1 im OpenSimulator-Code entfernt.
Angeben der Plugin-Implementierung in der Konfiguration
Bei den meisten Plugins wird die Klasse, die zur Implementierung der Plugin-Schnittstelle verwendet werden soll, explizit in einer der INI-Dateien angegeben. Die Anwendung lädt dann einfach die Assembly (DLL); findet die angegebene Klasse; und instanziiert es.
Diese Plugins werden verwendet, wenn es nur sinnvoll ist, eine einzige Implementierung des Plugins zu laden; nicht alle verfügbaren Implementierungen. Zum Beispiel kann nur ein Datenbankzugriffsmodul verwendet werden. Daher enthalten die INI-Dateien Anweisungen wie diese:
[DatabaseService] StorageProvider = "OpenSim.Data.MySQL.dll"
Manchmal gibt die Definition auch an, welche Klasse verwendet werden soll. Beispielsweise:
[InventoryService] LocalServiceModule = "OpenSim.Services.InventoryService.dll:XInventoryService"
Nehmen wir das Beispiel des Datenzugriffs-Plugins weiter. Für die meisten Klassen, die auf die Datenbank zugreifen müssen, ist eine Datenschnittstelle definiert. Zum Beispiel definiert PresenseService IPresenceData. Diese Schnittstelle verfügt über Implementierungen für alle Datenbanken, die OpenSimulator unterstützt. Wenn der Dienst gestartet wird, lädt er die Datenbankassembly, die in der Konfiguration angegeben wurde, und sucht dann in dieser Assembly die Klasse, die die gewünschte Schnittstelle implementiert (IPresenceData). Der Code sieht ungefähr so aus (obwohl dies vereinfacht ist):
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>().
