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.