Programm-Funktionalität in Plugins auslagern

[YannVDC]

Hallo Leute!

Meine erste Frage zu Lazarus ;o) Ich komm mal gleich zum Thema: Ich plane eine Software für Kreativitätstechniken. Ich weiß nicht, ob ihr das kennt, aber es gibt eine Unzahl an Techniken zur Ideenfindung, Problemlösung, Kreativität, etc... Ich möchte mehrere davon programmtechnisch umsetzen.

Das heißt die Software wird anfangs eine Art Grundfunktionalität anbieten, was heißt das, nun ja, man könnte es als rudimentäre PM-Funktionalität (=Projektmanagement) bezeichnen. Dann würde ich nach und nach eine neue Krea-Technik hinzufügen. Ich schätze es wird schwer sein, alle Techniken für die ich Unterlagen habe umzusetzen, das wären etwa 50 Stück, aber 20-30 könnten sicher drin sein. Und hier nun mein Problem: Ich könnte es ganz einfach machen und dann einfach bei den Updates die Exe-Dateien überschreiben, dann bietet sie nach dem Update eben 5 statt vorher 2 Techniken zur Auswahl. Nur wenn das so weiter wächst auf die 20-30 wird das sehr unübersichtlich, vor allem wird kein Mensch/Unternehmen alle brauchen.

Jetzt würde ich es eben gerne als Plugin (Modul, Package, wie auch immer man es nennen mag) lösen. Das heißt: Das Programm an sich bietet eigentlich nur die Grundfunktionalität (eben PM-Funktionen, div. Einstellungen, Sprachenverwaltung, Pluginverwaltung) und dann kann ich je nach Wunsch Kreatechnik-Plugins dazu installieren. So weit so gut, aber wie ist das technisch in Lazarus umsetzbar? Da ich bisher hauptsächlich mit Interpreter-Sprachen gearbeitet hab, fehlt mir hier einfach der Durchblick. Beim Interpreter ist es simpel, weil ich einfach nur das zusätzliche Sourcecode-File einbinden muss, aber wie mache ich es eben bei compilierten Geschichten?

Hat hier jemand einen Ansatz wie ich das machen könnte?

lg, Yann

[Live]

Eventuell könntest du mit Librarys (DLLs unter WIN) arbeiten, die zumindest Funktionen etc. storen können.

[theo]

Du kannst auch Pascal scripten:
http://wiki.lazarus.freepascal.org/Pascal_Script" onclick="window.open(this.href);return false;

[YannVDC]

Eventuell könntest du mit Librarys (DLLs unter WIN) arbeiten, die zumindest Funktionen etc. storen können.

Das wär eine Möglichkeit, ja, hab zwar vergessen zu erwähnen das ich prinzipiell immer für MacOSX, Linux UND Windows progge, aber da sollten ja auch Libraries möglich sein.

Hab mir Pascal-Script kurz angesehen, geht leider nicht unter Mac, also ist es schon tabu. ;o(

[af0815]

Soweit ich es bisher mitbekommen habe, kann man Forms nicht vernünftig (mit Lazarus) in Libraries auslagern (Ich lasse mich gerne eines besseren belehren).

[YannVDC]

Soweit ich es bisher mitbekommen habe, kann man Forms nicht vernünftig (mit Lazarus) in Libraries auslagern (Ich lasse mich gerne eines besseren belehren).

Oje, hhmmm, das müsste man mal ausprobieren, mehr als ein explodierender Rechner kann ja nicht passieren, oder?

[af0815]

Oje, hhmmm, das müsste man mal ausprobieren, mehr als ein explodierender Rechner kann ja nicht passieren, oder?

Nein, Schutzbrille und Schutzanzug nicht vergessen.

[carli]

Du musst dir natürlich überlegen, mit welcher Technik genau du welche Funktionalität auslagern willst.

Sind es nur weitere Exportier-Formate eines Editors, kannst du eine zusätzliche Scriptsprache einbinden,
dymanisches Linken sollte auch in die Option kommen, man kann ja bei der External-Klausel die Dateiendung weglassen, dann ist es plattformunabhängig.

[YannVDC]

Du musst dir natürlich überlegen, mit welcher Technik genau du welche Funktionalität auslagern willst.

Sind es nur weitere Exportier-Formate eines Editors, kannst du eine zusätzliche Scriptsprache einbinden,
dymanisches Linken sollte auch in die Option kommen, man kann ja bei der External-Klausel die Dateiendung weglassen, dann ist es plattformunabhängig.

Also so simpel sind die ausgelagerten Funktionalitäten nicht, das kann teilweise schon recht komplex werden, bin mir nicht sicher ob da eine Scriptsprache ausreicht. Wie meinst Du das mit dem dynamisch linken? Wie könnte ich da vorgehen?

[carli]

Pascal kennt 3 Typen von Quelldateien: program, unit und library.
program und library sind ähnlich, denn aus ihnen werden Dateien kompiliert.

Ein Beispiel für dynamisches Linken:

Code: Alles auswählen

program test;
 
function GetVersion: string; external 'lib_test';
begin
 writeln('Version: ' + GetVersion);
end.

Für die Library:

Code: Alles auswählen

library lib_test;
function GetVersion: string;
begin
 Exit('1.0');
end;
export GetVersion;
end.

Aus dem Kopf aufgeschrieben. Es könnte sein, dass die Library auch einen begin-end-Block braucht, oder dass es "exports" statt export heißt.
Die beiden Projekte kompilierst du auf jeden Fall und hast dann eine "lib_test\.(dll|so|dynlib)" (regexp-Ausdruck ), die in die Executable gelinkt wird. Diese Bibliothek kann man dann außerhalb der Laufzeit austauschen.

Wenn du zur Laufzeit die Bibliotheken auswechseln willst, ist der Aufwand noch etwas größer: Dann müsste in der Executable mit LoadLibrary (müsste eventuell 3mal gebaut werden wegen den Plattformen) die Bibliothek geladen werden und die Funktionen in Prozedurvariablen (type bla=procedure(argumente);) abgelegt werden, die dann so aufgerufen werden können.

[mschnell]

Als Techniken zum "Auslagern" fällt mir ein:

DLL, so, und was auch immer bei Mac
(ist nicht OS-unabhängig und funktioniert in Lazarus auch nicht so richtig. In Delphi gibt es dafür eine ordentliche Technik, aber eben nur auf Windows und vermutlich in der nächsten Version auch auf Linux)

.NET
bei .NET ist alles eine Library also geht es sicher (aber nicht mit Lazarus) Wenn man es richtig anlegt ist es auch System- und sogar CPU-unabhängig.

Script
u.U. sehr langsam

verbundene Programme
Wenn die Programme über Pipes oder TCP/IP kommunizieren, sollte es System-unabhängig lösbar sein. RemObjects ist ein sehr schönes Tool um so etwas zu organisieren. Ist auch für FPC spezifiziert, abe4r nicht kostenlos.

-Michael

[YannVDC]

DLL, so, und was auch immer bei Mac
(ist nicht OS-unabhängig und funktioniert in Lazarus auch nicht so richtig. In Delphi gibt es dafür eine ordentliche Technik, aber eben nur auf Windows und vermutlich in der nächsten Version auch auf Linux)

Wäre sicher die sauberste Lösung und käme am nähesten an eine "Plugin-Lösung" heran, hab aber auch selbst andere Foren-Einträge gefunden, wo über Probleme bei LCL in DLLs berichtet wurde. Es ist auch ein Bugreport darüber für Lazarus vorhanden, der auf "Acknowledged" steht. Ich werd mal ein bisschen damit herumprobieren, weil das Thema Libraries (zumindest aus Programmen darauf zugreifen) schon ein interessantes Thema ist.

.NET
bei .NET ist alles eine Library also geht es sicher (aber nicht mit Lazarus) Wenn man es richtig anlegt ist es auch System- und sogar CPU-unabhängig.

Mit Mono (für die die es nicht wissen: OpenSource-Klon von .NET) wäre das sicher möglich, aber aus verschiedenen Gründen ist für mich .NET/Mono tabu.

Script
u.U. sehr langsam

Da stimme ich Dir zu, sobald das "Plugin" etwas komplexere Funktionalität bietet, ist das Risiko sehr groß, dass es sehr langsam läuft. Als eine Art "Embedded-Macro" o.ä. ist es aber sicher eine interessante Sache, aber eben nur als Aufsatz, nicht als Basis.

verbundene Programme
Wenn die Programme über Pipes oder TCP/IP kommunizieren, sollte es System-unabhängig lösbar sein. RemObjects ist ein sehr schönes Tool um so etwas zu organisieren. Ist auch für FPC spezifiziert, abe4r nicht kostenlos.

Daran habe ich auch schon gedacht. Vorteil dabei: Man könnte die Module auch unabhängig vom Grundprogramm aufrufen um zu arbeiten. Trotzdem wäre es wenn ich das Programm mit meinen "Plugins" als EIN PROGRAMM sehe nicht die schönste Lösung.

Ich werd jetzt mal die Fühler in 3 Richtungen ausstrecken:

1. ich schau mir die Library-Geschichte mal genauer an und probiere da herum, wo es hängt, ob es für meine Bedürfnisse vielleicht ein Workaround gibt.
2. Ich schau mich nach Scriptlösungen um, die man implementieren kann.
3. Ich teste das Zusammenspiel/Verbinden von Programmen.

Ist jetzt vielleicht etwas viel, hätte gern schon DIE Lösung, aber ich denke der Lernfaktor wird auch riesig sein und evtl. kann ich die Technik, die für dieses Projekt fehlschlägt, später mal brauchen.

Ich sag erstmal schon VIELEN HERZLICHEN DANK für die Antworten/Hinweise. Ich seh schon, das Forum ist sehr aktiv und es sind doch einige recht erfahrene Leute dabei. ;o)

lg, Yann

PS: Ich schließe damit den Topic natürlich nicht, falls noch wer nen Ansatz/Hinweis/Ratschlag hat, kann er ihn gerne posten. Falls ich für den einen oder anderen Punkt Ergebnisse hab (egal ob positiv oder negativ), würde ich sie hier posten.

[af0815]

Zum Thema Forms in dll:
Form in Library
0007182: Problems using LCL in DLL
0015126: Reparenting forms within a library

[YannVDC]

Zum Thema Forms in dll:
Form in Library
0007182: Problems using LCL in DLL
0015126: Reparenting forms within a library

Jep, die ersten 2 Links kenne ich, auch schon gesehen, der 3. ist mir neu. Mal sehen was es mit dem Workaround auf sich hat, der dort gepostet wurde.

[mschnell]

3. Ich teste das Zusammenspiel/Verbinden von Programmen.

Die passende Technik heißt "RPC" ("Remote Procedure Call") Rem,Objects macht genau das. Man braucht dafür neben dem Transport-Mechanismus einen "Marshalizer", der die Parameter in eine Datenstruktur ("offiziell: XML, andere Formate sind kompakter) packt. Bei RemObj kann man sich die Kodierung und den Transportmechnismus einzeln aus einer Anzahl Alternativen auswählen. Die "offizielle" Technik ist "SOAP": XML Struktur über HTTP Transport.

Wenn es so etwas als open source gäbe, wäre natürlich sehr schön. Muss ja nicht SOAP können. wenn erst mal die Units für einen Transport eines proprietären Formats durch Pipes vorhanden wären, wäre das ein Toller Ausgangspunkt.

Du brauchst einen Thread der auf eine Message aus der Pipe wartet und die dekodiert und dann (im einfachsten Fall mit Synchronzie) ein Event im Maintread mit den richtigen Parametern aufruft und idealer Weise ein Funktionsergebnis und "out" Parameter zurück-überträgt.

Das fände ich in jedem Fall die beste Lösung für ein Plugin-Interface

-Michael