RemObjects sieht jetzt auf den ersten Blick wirklich mächtig und gleichzeitig elegant aus. Gleichzeitig habe ich aber weiterhin das Gefühl, dass es ein ziemlicher Overkill ist.
Nach bisheriger Planung muss ein Plug-In nicht mehr leisten als
- Von einem anderen Prozess (dem Kern) seine Konfiguration empfangen (bsp. als XML)
- Einen Befehl "Fange an, zu arbeiten" entgegennehmen, ebenso "Fahre dich herunter"
- seine Oberfläche (bsp. VCL-Form) anzeigen, ebenso verstecken (bzw. Form zerstören)
- seine (durch den Benutzer über die Oberfläche veränderte) Config wieder zurückgeben
Bislang geregelt habe ich das über DLLs die in den Prozess (als separater Thread) eingeklinkt werden. Auf die Nachteile wenn hier etwas abstürzt (und ich bsp. serielle Ports nicht mehr freibekomme) müssen wir sicher nicht mehr reden. Deshalb war der Ansatz, es in gesonderte Prozesse zu packen.
Bislang möchte ich im Kern noch nicht einmal wissen, was in den Plug-Ins vor sich geht und wie sie funktionieren. Mit so einem simplen Weltbild bleibt allerdings eine brauchbare Visualisierung auf anderen Maschinen außen vor, oder?
Insgesamt stehe ich irgendwie vor dem Dilemma, mich im Kern nicht damit befassen zu wollen, was in einem Plug-In vor sich geht und was es kann,
aber trotzdem die Möglichkeit behalten möchte, das Plug-In (oder die gesamte Anwendung) später einmal über einen Webbrowser oder eine native Anwendung auf einem anderen System zu steuern. Und das führt auch mittlerweile schon wieder etwas weg vom eigentlichen Thema, ob nun Sockets, Pipes oder Mega-Lösung wie RealThinClient, RemObjects oder sonstwas.
