Minimalistisches PlugIn-System

[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

[FredlFesl]

Hi,

Ich habe mal Folgendes gemacht (alles so wie dein Vorschlag, also Verzeichnis durchsuchen, DLL laden usw.):
Jede DLL exportiert neben den Prozeduren "GetName" und "Initialize" (dazu später) beliebige Prozeduren.
Das Einzige, was diese beliebigen Prozeduren gemein haben, ist die Schnittstelle, denn sie sehen alle so aus:

Procedure SomeDLLProcedure (inParam : OleParam, var result, outParam : OleParam);

Ein- und Ausgabeparameter können also Arrays, Streams oder was auch immer sein. Result ist entweder unassigned oder enthält einen Fehler (gestreamed).

Aufgerufen wurden die über einen Plugin-Manager. Nehmen wir an, wir haben eine DLL "MyDLL" und die hat die Prozeduren "Proc1" und "Proc2". Dann rufe ich eine Prozedur der DLL so auf:
ThePluginManager.Call ('MyDLL.Proc1', inParam, result, outParam);

Ich habe damit also eine allgemeine Schnittstelle, die ich beliebig erweitern kann.
Der Plugin-Manager ist auch für die Kommunikation zwischen den DLL verantwortlich, denn er übergibt der DLL per exportierter 'Initialize' Prozedur eine Callback-Schnittstelle, sodaß auch ein Plugin über die gleiche -eben beschriebene Schnittstelle- ein anderes Plugin aufrufen kann. Oder definierte Routinen der Hauptanwendung..

Bei mir gab es in dem Sinne keine Hauptanwendung, denn die DLL implementierten einen Webservice, wobei die einzelnen 'Anwendungen' eben diese DLLs waren.

Desweiteren habe ich dafür gesorgt, das die DLL zur Laufzeit ausgetauscht werden können, ohne die Anwendung (den Service) beenden zu müssen. Die neue oder auszutauschende DLL kann man per TCP direkt in den Service impfen. Der packt die DLL in das Plugin-Verzeichnis, entfernt die alte Version und ab einem definierten Zeitpunkt werden alle Aufrufe an die neue DLL geleitet.

War ziemlich cool und hat auch gar nicht mal so viel Code.

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