Minimalistisches PlugIn-System

[r2c2]

Zum Design der Schnittstelle kannst du dir mal das angucken: http://www.christian-rehn.de/2011/08...er-api-design/ Fand ich ganz interessant.

mfg

Christian

[Florian Hämmerle]

Zitat von r2c2:

Fand ich ganz interessant.

Der Googletalk breitet sich in der DP langsam aus. Hab ich vorhin auch gerade in nem Thread drauf verwiesen

mfg Florian

BTT: Ansonsten wäre es vielleicht auch ne Möglichkeit, die Schnittstelle über eine der Scriptengines (SE2, PS, etc.) ansprechbar zu machen, dann braucht man nicht extra DLLs zu schreiben, sondern kann zum Produkt einen kleinen Plugin-Editor mitliefern. Vor allem littleDaves SE2 dürfte sich für diesen Zweck anbieten. Aus deiner Hauptanwendung machst du dann einfach bestimmte Objekte für die Scriptengine verwendbar und schon kann man in einem Object Pascal Dialekt eigene Plugins schreiben.

[hanspeter]

Mit dll als Plugin kann man früher oder später auch ganz schön auf die Schn... fliegen.
Es verstecken sich 4 größere Problemchen.
1. Ich muss mit BPL arbeiten. Die müssen alle mit der gleichen Compilerversion in der gleichen Umgebung compiliert sein.
Wird (ausversehen) mal eine Init neu compiliert kommt gerne der Fehler ... wurde mit unterschiedlicher Version compiliert- und das erst beim Kunden.
2. Verwechselt jemand völlig gleichnamige BPL in unterschiedlichen Verzeichnissen, dann ist die BPL Hölle los.
3. Der Linker ist garnicht mehr so smart. Liegt auch daran, das im Initialisierungsteil einer Unit Code liegt.
Ich habe mein Programm mal auf einem Delphi-freien Rechner installiert und die von mir als Laufzeit angegebenen BPL dazu.
Danach musste ich noch 76 weitere BPL kopieren, darunter die BDE bis das Programm startfähig war.
4. Delphi registriert bei Windows Klassen über den Klassennamen.
Wird diese Klasse (z.B. Fastreport) in einer weiteren Dll verwendet, dann kommt die Fehlermeldung ...kann nicht geladen werden Klasse bereits registriert.
Der Fehler kommt irgendwann beim Kunden wenn in irgendeiner Konstellation dll A und B geladen werden und bei die gleiche Klasse verwenden wollen.
Die BPL ist so ein alter überflüssiger Zopf und Technologie des vorigen Jahrhunderts.

Um ein Plugin System in Delphi zu realisieren, haben sich bei uns 3 Wege als gangbar erwiesen.
1. Die Installation des Plugin als Comserver.
2. Die Installation des Plugin als Exe und der Verkehr über Aufrufparameter und Exitcode.
Werden mehr Daten benötigt, die Verbindung über ein Memmory mapped File.
Wenn es eine Client-Server Anwendung werden soll, erprobe ich gerade ein weiteres interessantes Verfahren.
Daten werden auf den Server zurückgeschrieben. Ein Trigger reagiert darauf und startet eine Storedprocedure. Diese macht nichts weiter als einen Job auf einen Stack abzulegen.
Dieser Job wird dann von dem Serverprogramm abgearbeitet.

Gruß
Peter

[Stevie]

Zitat von hanspeter:

Mit dll als Plugin kann man früher oder später auch ganz schön auf die Schn... fliegen.
Es verstecken sich 4 größere Problemchen.
1. Ich muss mit BPL arbeiten. Die müssen alle mit der gleichen Compilerversion in der gleichen Umgebung compiliert sein.
Wird (ausversehen) mal eine Init neu compiliert kommt gerne der Fehler ... wurde mit unterschiedlicher Version compiliert- und das erst beim Kunden.
2. Verwechselt jemand völlig gleichnamige BPL in unterschiedlichen Verzeichnissen, dann ist die BPL Hölle los.
3. Der Linker ist garnicht mehr so smart. Liegt auch daran, das im Initialisierungsteil einer Unit Code liegt.
Ich habe mein Programm mal auf einem Delphi-freien Rechner installiert und die von mir als Laufzeit angegebenen BPL dazu.
Danach musste ich noch 76 weitere BPL kopieren, darunter die BDE bis das Programm startfähig war.
4. Delphi registriert bei Windows Klassen über den Klassennamen.
Wird diese Klasse (z.B. Fastreport) in einer weiteren Dll verwendet, dann kommt die Fehlermeldung ...kann nicht geladen werden Klasse bereits registriert.
Der Fehler kommt irgendwann beim Kunden wenn in irgendeiner Konstellation dll A und B geladen werden und bei die gleiche Klasse verwenden wollen.
Die BPL ist so ein alter überflüssiger Zopf und Technologie des vorigen Jahrhunderts.

Dem kann ich nicht ganz zustimmen:
zu 1. Entwickelt euer Kunde eigene Plugins? Dann muss er natürlich die korrekten Dateien der BPLs bekommen. Wenn nicht, dann kann der "wurde mit unterschiedlicher..." Fehler nicht kommen. Oder die Anwendung wurde einfach schlampig getestet (auf einem Rechner, der keine Delphi Installation enthält)

zu 2. BPLs im Programm Verzeichnis -> keine Probleme

zu 3. Dann hast du wohl die falschen Runtime packages in deinem Programm angegeben oder in deiner eigenen BPL required. Ich hab selber schon erlebt, dass Leute null Plan von BPLs haben und was in welchen Packages zu finden ist, so dass total unnötige Packages required und demzufolge und ausgeliefert wurden.

zu 4. Genau deshalb benutzt man ja Runtime packages. In dem Fall würde man das Fastreport Package requiren.

Die BPL Technologie mag schon alt sein, deshalb ist sie aber nicht schlecht. Wie bei vielem kann man sich aber viel Ärger einhandeln, wenn man sie nicht zu beherrschen weiß.

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

[hanspeter]

Zitat von Stevie:

Oder die Anwendung wurde einfach schlampig getestet (auf einem Rechner, der keine Delphi Installation enthält)

zu 3. Dann hast du wohl die falschen Runtime packages in deinem Programm angegeben oder in deiner eigenen BPL required. Ich hab selber schon erlebt, dass Leute null Plan von BPLs haben und was in welchen Packages zu finden ist, so dass total unnötige Packages required und demzufolge und ausgeliefert wurden.
Wie bei vielem kann man sich aber viel Ärger einhandeln, wenn man sie nicht zu beherrschen weiß.

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.

Peter

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