Minimalistisches PlugIn-System

[ele]

Der "Dritthersteller" kann manchmal auch ein Alter Ego aus der Vergangenheit sein...

[Stevie]

DLL basierte Plugin Systeme haben immer das Problem, dass man sehr schlecht komplexe Daten (Objekte) austauschen kann. Forms und Frames aus DLLs sind auch immer anfällig für Ärger. Dafür braucht man dann wieder BPLs, gegen die dein Programm und die Plugins gelinkt sind. Auch stellt sich die Frage, wieviel Wissen steckt in den Plugins? Stichwort Menü: hängen die Plugins sich selber da rein, weil sie das Menü übergeben bekommen (nicht gut) oder geben sie bloß eine Liste der Aktionen und die Anwendung hängt sie an. Wie stellt die Anwendung fest, wo sie hinkommen?

DSharp hat übrigens auch einige Units, mit denen man mit wenigen Handgriffen ein Plugin System bauen kann (angelehnt an MEF)

[Elvis]

Zitat von Stevie:

DLL basierte Plugin Systeme haben immer das Problem, dass man sehr schlecht komplexe Daten (Objekte) austauschen kann. Forms und Frames aus DLLs sind auch immer anfällig für Ärger.

Es gibt in Windows einen binär kompatiblen Standard um Objekte auszutauschen: COM. Allerdings stinkt COM und zwar gewaltig.
Das schöne an diesem stinkenden Kadaver ist aber, dass es eben diesen Standard für Objekte hinterlassen hat. Delphis Interfaces implementieren immer IUnknown, die Grundlage aller COM Objekte.
Außerdem ist das Layout von Delphi-Interfaces kompatibel mit allen Sprachen, die IUnknown unterstützen.
Delphis OleVariant ist nur Compiler Magic über IDispatch, welches in der alten COM-Ära für dynamic scripting zuständig war.
Referenzzählung ist auch ein Standard in der COM-Welt, nicht unbedingt erzwungen und autom. wie in Delphi, aber dennoch weiß ein C++-Dev, der ein IUnknown sieht, dass und wie er _AddRef und Release bedienen muss.
Long story short:
Kombiniere klassische DLLs (nicht COM-infizierte Mistviecher!) mit Interfaces, und du bekommst eine Sprach- und Compiler- unabhängige PlugIn-Platform, bei der man nicht mit so grauenvoll plattgedrückten, absolut scheußlichen APIs rumwickeln muss. Damit meine ich die klassische Art, bei der Leute glauben alle exportierten Funktionen dürften nur aus primitiven Typen bestehen...

Die Hostapp würde kaum mehr als einen Service Locator übergeben, und auch einige sinnvolle Services wie Menüverwaltung, Dokumente, etc zur Verfügung stellen. Aber wirklich interessant wird es wenn Plugins selbst Services in den Locator registrieren können.
So dass Plugins von Knut Services von Plugins von Bert nutzen können...

Zitat:

Dafür braucht man dann wieder BPLs

BPLs sind etwas mit dem eigentlich NUR die Delphi-IDE sinnvoll arbeiten kann.
Denn BPLs haben solch komplett inakzeptable Einschränkungen wie: gleicher Compiler, gleiche BPLs, und alles nur Delphi!
Für die IDE mag das okay sein, die kann eh nur mit einer Delphi-Version auf einmal arbeiten und Delphi als erzwungene Voraussetzung tut der IDE auch nicht soo sehr weh. Aber dir selbst willst du solche eine blödsinnige Einschränkung nicht auferlegen.
Das hieße nämlich, dass du niemals wieder auf eine höhere Delphi-Version umsteigen kannst, und deine plugin-schreibenden User auch nicht, da plötzlich alles in sich zusammenstürzen würde. Prost Mahlzeit!

Sorry für die lange Predigt, aber ich halte BPL-Plugins für die digitale Version der jährlichen Grippewelle: Wenn man die Leute nicht regelmäßig impft werden sie doch krank (benutzen BPLs)...

Edit: Man sollte nirgends, in keinem einzigen Binäry, auf (Runtime-)BPLs verweisen.
Hast du auch nur ein einziges von den Viecher in deinem Prozess war's das. Dann kannst du sofort einpacken, was Flexibilität oder niedrigen Blutdruck angeht.
Eine einzige BPL wird als Abhängigkeit mindestens die RTL mitbringen, und ab dem Moment mussu auch die RTL einer ganz speziellen Delphi-Version mitliefern.
Wenn Teile dieser BPL auch nur Teil deiner PlugIn-API sind, kannst du NIE WIEDER auf eine neuere Delphi-Version wechseln ohne alle PlugIns zu töten.

[Stevie]

Ich wüsste echt gerne, wie viele von den selbst gefrickelten Plugin Systemen, die ja ach so flexibel und Delphi unabhängig sind, tatsächlich auch so genutzt werden. In der Theorie ist das alles ganz toll. Aber die konkrete Anforderung zeigt letzlich, ob es tatsächlich externe Plugin Entwickler gibt, die andere Sprachen oder Delphi Versionen einsetzen. Und kommt mir jetzt nicht mit ja, im Firefox oder im Miranda kann ich das...

[Elvis]

Zitat von Stevie:

Ich wüsste echt gerne, wie viele von den selbst gefrickelten Plugin Systemen, die ja ach so flexibel und Delphi unabhängig sind, tatsächlich auch so genutzt werden. In der Theorie ist das alles ganz toll. Aber die konkrete Anforderung zeigt letzlich, ob es tatsächlich externe Plugin Entwickler gibt, die andere Sprachen oder Delphi Versionen einsetzen. Und kommt mir jetzt nicht mit ja, im Firefox oder im Miranda kann ich das...

Wir benutzen eine Oracle-IDE, die mit Delphi geschrieben ist.
Die nutzt zwar grausige. platte DLLs, aber genau deshalb konnte ich problemlos einige Plugins in C# schreiben.
Der Hersteller benutzt mittlerweile sicherlich nicht mehr Delphi 4 oder 5, mit dem die erste Version rauskam. Und man findet Plugins aus allen möglichen Sprachen für eben dieses Programm.
Nur um dir ein Beispiel zu nennen, welches auch ein Delphi-Host ist.

[DeddyH]

hier ist ja richtig was los. Es ist vielleicht nicht richtig rübergekommen, aber mein Schwerpunkt liegt momentan weniger auf Flexibilität als mehr auf "Easy-to-use". Zu den zu exportierenden Funktionen, wie ich mir das bisher denke:
- "Titel" der Anwendung, ggf. Kurzbeschreibung
- eine Start-Routine
- ggf. Rückmeldung, wenn fertig

Das Hauptprogramm ermittelt also den Titel und fügt z.B. einen Menüpunkt in sein Menü ein. Die Kurzbeschreibung könnte dann für Hints o.ä. verwendet werden. Zusätzlich muss sie sich natürlich merken, welche DLL das war. Wird nun ein Menüpunkt angewählt, wird die DLL geladen, die Start-Routine aufgerufen und auf Rückmeldung gewartet (Message oder so), anschließend wieder entladen und fertig. So ist mein bisheriger Gedankengang.

[Iwo Asnet]

Zitat von DeddyH:

..als mehr auf "Easy-to-use". Zu den zu exportierenden Funktionen, wie ich mir das bisher denke:
- "Titel" der Anwendung, ggf. Kurzbeschreibung
- eine Start-Routine
- ggf. Rückmeldung, wenn fertig

Sowas haben wir auch: Ein Diagnosesystem für Maschinen. Das Plugin-System ist quasi eine Toolbox für unterschiedliche Diagnoseroutinen. Wenn der Techniker (Null Ahnung von Programmierung) irgendwo auf der Welt unterwegs ist und eine 'Spezialdiagnose' braucht, dann kann sich ein Programmierer hier kurz hinsetzen, schreibt die Diagnose als Plugin und schickt ihm die DLL. Der schmeisst sie ins Plugin-Verzeichnis, registriert die DLL und fertig. Wenn die DLL sich als praktisch erweist, kommt sie ins Standardportfolio.

Wir haben neben dem Namen und einer Kurzbeschreibung auch die Versionsnummer des Plugins mit aufgenommen.

Die Parametrierung des Plugins erfolgt über ein einfachen String der Form "Param1='1';Param2='xyz'". Dafür existiert der blöde TValueListEditor, der sonst zu nix zu gebrauchen ist. Wir wollten noch einen schicken tollen Parametereditor bauen, aber dafür müssten wir vom Plugin den Datentyp jedes Parameters wissen... Bisher hatte keiner Bock, das aufzubohren.

Es ist eine Anwendung, die an Spimplizität kaum zu über/unterbieten ist. Aber als Plugin-Framework ist es gut genug.

[Stevie]

Zitat von Elvis:

Wir benutzen eine Oracle-IDE, die mit Delphi geschrieben ist.

Toad? Und ja, wenn man eine kommerzielle Anwendung schreibt, die von Benutzern erweiterbar sein soll, dann stimmt das wohl. Daher sagte ich ja konkrete Anforderung.

Zitat von hanspeter:

Ich möchte mir die Anwürfe und Unterstellungen ausdrücklich verbitten.
Genau wegen der beschriebenen Probleme haben wir die Neuentwicklung in Delphi schon vor längerer Zeit eingestellt.
Aber schön wenn Delphi noch von einigen Fanatikern verteidigt wird.

Ich sprach von meinen Erfahrungen. Soll auch schon einige Delphi Entwickler gegeben haben, die große Anwendungen ohne Probleme mit Runtime Packages entwickelt haben.

[gsh]

Ich hab vor langer langer Zeit mal einen Codelib beitrag für ein kleines Plugin System geschrieben, vielleicht bringt dich das auf Ideen:
http://www.delphipraxis.net/73567-fl...ginsystem.html
Die Diskussion dazu ist auch recht interessant:
http://www.delphipraxis.net/74448-fl...iskussion.html

[mschaefer]

Das Problem mit en PlugIn-Systemen ist, dass es meist Insellösungen sind. Um das vom Zeitaufwand in den Griff zu bekommen habe ich dies auch mit eigenständigen Anwendugen gemacht, die nur mit einem versteckten Aufrufparameter starteten. Der Datenaustausch läuft über xml-Files. Es war angedacht es über einen zentraln SOAP-Server zu steuern, aber dazu ist es nie gekommen. Also kurzum, ist ein gangbare Weg aber nicht der Weisheit letzter Schluß.

Grüße