Aki's Vibes

[Akira]

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.

• 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.

[Akira]

Huhu zusammen,

tl:dr Dll im bin verzeichnis ohne Source

In einem dem letzten Beitrage hab ich ja angekündigt den SmartThreadPool auszubauen. Ok das war kein grosses Ding. Claude brauchte genau 13 Minuten dafür und alles funktionierte auf Anhieb.

Nun kommt ein wesentlich komplizierteres Projekt: Die Änderungen vom OpenSim in meinen Sim hineinmergen. Mit Claude lass ich das nicht machen. Da gehe ich lieber händisch vor. Die Schwierigkeit: Vor einiger Zeit habe ich auf eine flache Struktur umgestellt. Die flache Struktur der Verzeichnisse entspricht der Projektstruktur, wie wir sie beispielsweise in der IDE sehen:



OpemSim hat seine Struktur jedoch in Verzeichnis Hierarchien abgelegt also beispielsweise OpenSim/Data/MySql. Ich hatte die Hoffnung, dass ich, wenn ich mit Symlinks die OpenSim Struktur nachbilde, der Merge einfacher ist. Leider hab ich schon zu viel geändert da muss ich ein anderes Vorgehen wählen.

Einige Dateien hatte ich bereits umgestellt, da fiel mir etwas auf: Nini hat sich geändert! Das ist hässlich! Klar das einfachste ist aus dem originalen OpenSim die korrekte Nini.dll holen und das Problem ist gelöst. Ich will das aber nicht, siehe meine früheren Posts. Libraries, welche ich nicht selbst baue sollen vom NuGet Repository bezogen werden. Im Falle der Nini.dll habe ich ein wenig geforscht. OpenSim hat die notwendige Info bereits gespeichert. In den ThirdPartyLicenses sind all die Lizenzen abgelegt, unter welchen die entsprechende Libraries veröffentlicht werden. In der Nini Lizenz sehe ich folgenden Entwickler: Brent R. Matzelle. Es existiert sogar ein Github Repository https://github.com/bmatzelle/nini

Zusätzlich gibt es diverse NuGet Repositories welche die entsprechende DLL zur Verfügung stellen. Bloss:



EnvConfigSource welche von OpenSim reingemerged wurde, existiert im Original nicht !!! Korrekt wäre in diesem Fall: Einen Pull Request an den Owner des https://github.com/bmatzelle/nini Source Repository, damit er eine neue Version baut. Falls er diese Aenderungen aus welchen Gründen auch immer nicht möchte, ein neues Repository erstellen und den Link irgendwo deutlich dokumentieren. Einfach eine neue Datei Nini.dll in dem bin Verzeichnis abzulegen ist in der heutigen Zeit nicht mehr State of the Art.

Wer weiss wo ich die Sourcen zur aktuellen Nini.dll finde und auch zu sämtlichen andern Third Party libraries. Für Sachdienliche Hinweise bin ich äusserst dankbar!

Liebe Grüsse
Akira

[Christoph Balhaus]

Wer weiss wo ich die Sourcen zur aktuellen Nini.dll finde und auch zu sämtlichen andern Third Party libraries. Für Sachdienliche Hinweise bin ich äusserst dankbar!

In https://github.com/opensim/opensim-libs hast du schon geschaut? Oder sind die Nini Sourcen darin nicht mehr aktuell? Ich habe das selber noch nicht genutzt...

[Akira]

In https://github.com/opensim/opensim-libs hast du schon geschaut? Oder sind die Nini Sourcen darin nicht mehr aktuell? Ich habe das selber noch nicht genutzt...

Vielen Dank Christoph! Habe kurz nachgeschaut. Folder trunk ist der Schlüssel, da hat es zwei Folder managed und unmanaged und im managed ist's drin zusammen mit den andern repos und sogar mit den entsprechenden Anpassungen!

Warum es in Nuget nicht zu finden ist, wird im Read.me schnell klar. Hier steht:

Opensim will avoid to use Nuget whenever possible. In same cases we may extract and use only the files we need out of the nuget packages garbage.

Okay, wenn die Nuget schon als garbage bezeichnen. 99.9% der Entwickler sehen das wohl anders. Nuget ist offizieller Standard und heutzutage entwickelt niemand mehr ohne Library Management. Hat durchaus Vorteile. Automatische Versionskontrolle, automatische Security Scans. Klar unterbricht es den flow etwas, wenn deine Pipeline failed, wenn du plötzlich eine vulnerability drin hast. Aber typischerweise sind dies rasch gefixt und man kann das Projekst schnell auf die gefixte Version anheben. Für mich sieht Garbage anders aus.