09.02.2026, 01:16
Huhu zusammen,
tl;dr In diesem Vibe geht es ums Aufräumen. Gedanken zu Plugins, Dependency Injection und Factories.
Diese Woche hab ich nicht viel am Simulator rumgevibed. War anderweitig engagiert. Deshalb erzähle ich nun etwas zu der Idee, warum ich am Sim oder genauer gesagt dem Region-Server rumwerkle. Was mich eigentlich schon längere Zeit stört, der Region-Server ist überladen! Eigentlich beginnt das schon beim Namen. Neben dem Region-Server, gibt es ja noch den Grid-Server, der "Robust" genannt wird. Ausser der Region Server wird im Standalone Modus betrieben, dann ist die Funktionalität im Region Server eingebaut, besser gesagt zusammengesteckt.
Dieses zusammenstecken ist im Prinzip eine spannende Sache, so können die Module im Region-Server für Standalone und im Robust Server wiederverwendet werden. Auch wird die Möglichkeit geboten, Plugins für den Simulator zu entwickeln. So weit, so gut. Ein Plugin System wird dann richtig lustig, wenn es dann irgendeinen Marketplace gäbe, in welchem Plugins geholt werden können, mit denen der Simulator mit Funktionalität erweitert werden könnte. Leider hat sich diesbezüglich ausser einigen Money Plugins nicht sehr viel entwickelt. Schön wäre es, wenn die Trennung zwischen dem Grundgerüst und den Plungins sauberer getrennt wären, sodass ich, falls ich gerne die Ubode Physik hätte, beispielsweise ein bereits geliefertes Physik Plugin austauschen könnte. Aktuell sind all diese Module oder Plugins mehr oder weniger wild im Code verteilt. Es existiert ein Folder addon-modules. Aber im OpenSim Code Folder existieren ebenfalls zwei Projekte OpenSim.Addon.Groups und OpenSim.Addon.OfflineIM. Und das ganze noch in mehreren Ausprägungen.
Für meinen Geschmack zu viel Durcheinander. Und wir Schweizer mögen Durcheinander nicht. Wir lieben es aufgeräumt. Wir räumen gerne alles auf:
Also hab ich mir ein paar Gedanken gemacht, was ich eigentlich gerne möchte.
Auch wenn die Konzeption der Mono.Addins ziemlich cool ist, die Tatsache, dass es nicht mehr weiterentwickelt wird und auch das Plugin Konzept nicht so prickelnd umgesetzt ist, sagte ich mir: Raus damit!
Um mit Modulen umzugehen, existieren mehrere Muster:
Die drei Muster im Vergleich
Plugin-System (Mono.Addins, System.Composition)
Dependency Injection (DI Container)
Factory
Aktuell hab ich mich für eine Factory-Lösung entschieden. Aber könnte mir vorstellen, dass wenn ich das Testing überarbeite, ich vermehrt auf Dependency Injection umsteigen werde. Schon seit einiger Zeit erledigt:
Hab den Sim schon mal angetestet, aber es traten noch einige Seiteneffekte auf also wieder zurück ins Labor. Und genau deshalb überleg ich mir auch den Smart Thread Pool zu entfernen, um noch mehr Standardkomponenten zu verwenden, mit dem finalen Ziel keine .dll mehr im Github Repository und alles mit NuGet managen. Bin mal gespannt, wozu ich nächste Woche komme.
Ob das ganze jemals die Qualität hat um im Grid eingesetzt zu werden, weiss ich noch nicht. Die Vibes sind Sachen an welchen ich im Moment herumexperimentiere, immer mit einem konkreten Ziel welches ich habe.
tl;dr In diesem Vibe geht es ums Aufräumen. Gedanken zu Plugins, Dependency Injection und Factories.
Diese Woche hab ich nicht viel am Simulator rumgevibed. War anderweitig engagiert. Deshalb erzähle ich nun etwas zu der Idee, warum ich am Sim oder genauer gesagt dem Region-Server rumwerkle. Was mich eigentlich schon längere Zeit stört, der Region-Server ist überladen! Eigentlich beginnt das schon beim Namen. Neben dem Region-Server, gibt es ja noch den Grid-Server, der "Robust" genannt wird. Ausser der Region Server wird im Standalone Modus betrieben, dann ist die Funktionalität im Region Server eingebaut, besser gesagt zusammengesteckt.
Dieses zusammenstecken ist im Prinzip eine spannende Sache, so können die Module im Region-Server für Standalone und im Robust Server wiederverwendet werden. Auch wird die Möglichkeit geboten, Plugins für den Simulator zu entwickeln. So weit, so gut. Ein Plugin System wird dann richtig lustig, wenn es dann irgendeinen Marketplace gäbe, in welchem Plugins geholt werden können, mit denen der Simulator mit Funktionalität erweitert werden könnte. Leider hat sich diesbezüglich ausser einigen Money Plugins nicht sehr viel entwickelt. Schön wäre es, wenn die Trennung zwischen dem Grundgerüst und den Plungins sauberer getrennt wären, sodass ich, falls ich gerne die Ubode Physik hätte, beispielsweise ein bereits geliefertes Physik Plugin austauschen könnte. Aktuell sind all diese Module oder Plugins mehr oder weniger wild im Code verteilt. Es existiert ein Folder addon-modules. Aber im OpenSim Code Folder existieren ebenfalls zwei Projekte OpenSim.Addon.Groups und OpenSim.Addon.OfflineIM. Und das ganze noch in mehreren Ausprägungen.
Für meinen Geschmack zu viel Durcheinander. Und wir Schweizer mögen Durcheinander nicht. Wir lieben es aufgeräumt. Wir räumen gerne alles auf:
Also hab ich mir ein paar Gedanken gemacht, was ich eigentlich gerne möchte.
- Brauche ich Robust? Nö ich habe den Php-Gridserver
- Brauche ich die Standalone Möglichkeit? Nö ich betreibe Sims nur im Hypergrid Modus.
- Brauche ich 10 Physik-Engines? Nö, Ubode und Bullet reichen eigentlich. Bullet brauch ich nur wegen der 3D Meshes die ich importiert hab, weil bei Ubode müsste ich nochmals importierten.
- Scripting Engines. Hat sich inzwischen auf eine reduziert. Glücklicherweise.
- Weitere Modules die ohne Sinn und Zweck rumliegen entfernen.
- Mono.Addins als Plugin System loswerden wird nicht mehr weiterentwickelt. Brauch ich wirklich Plugins?
Auch wenn die Konzeption der Mono.Addins ziemlich cool ist, die Tatsache, dass es nicht mehr weiterentwickelt wird und auch das Plugin Konzept nicht so prickelnd umgesetzt ist, sagte ich mir: Raus damit!
Um mit Modulen umzugehen, existieren mehrere Muster:
- Plugins
- Dependency Injection
- Factories
Die drei Muster im Vergleich
Plugin-System (Mono.Addins, System.Composition)
- Findet automatisch Implementierungen in Assemblies
- "Zeig mir alle Klassen, die ICommand implementieren"
- Für unbekannte, dynamische Erweiterungen
Dependency Injection (DI Container)
- Verwaltet Objektlebensdauer und injiziert Abhängigkeiten
- "Gib mir die registrierte Implementierung von ILogger"
- Für lose Kopplung innerhalb bekannter Komponenten
Factory
- Kapselt Objekterstellung mit Logik
- "Erstell mir ein Objekt basierend auf diesen Runtime-Parametern"
- Für komplexe oder parameterabhängige Instanziierung
Aktuell hab ich mich für eine Factory-Lösung entschieden. Aber könnte mir vorstellen, dass wenn ich das Testing überarbeite, ich vermehrt auf Dependency Injection umsteigen werde. Schon seit einiger Zeit erledigt:
- Mono.Addins rausfakturiert und durch Factories ersetzt
- Module die nur für den Standalone Betrieb notwendig sind entfernt
- Uralte Module die nicht mehr notwendig sind entfernt
Hab den Sim schon mal angetestet, aber es traten noch einige Seiteneffekte auf also wieder zurück ins Labor. Und genau deshalb überleg ich mir auch den Smart Thread Pool zu entfernen, um noch mehr Standardkomponenten zu verwenden, mit dem finalen Ziel keine .dll mehr im Github Repository und alles mit NuGet managen. Bin mal gespannt, wozu ich nächste Woche komme.
Ob das ganze jemals die Qualität hat um im Grid eingesetzt zu werden, weiss ich noch nicht. Die Vibes sind Sachen an welchen ich im Moment herumexperimentiere, immer mit einem konkreten Ziel welches ich habe.



![[-]](https://www.gridtalk.de/images/collapse.png)