Isolation von Plugins

Dravere schrieb:

Die Frage ist halt, muss ich den Plugin-Entwickler davon abhalten, wenn er probiert über Reflection auf Komponenten des Hauptprogrammes zuzugreifen. Um den Plugin-Entwickler vor sich selbst zu schützen oder aber den Benutzer des Programmes zu helfen, schlechte Plugins fernzuhalten?

Machst Du dir auch bei gewöhnlichen .NET-DLLs diese Gedanken?

Mit Reflektion kann man jede Kapselung aufbrechen und wer das tut hat die Konsequenzen zu tragen.

Dravere

µ @ work schrieb:

Machst Du dir auch bei gewöhnlichen .NET-DLLs diese Gedanken?

Gewöhnliche DLLs sind ja auch was anderes. Dort weiss man woran man ist. Was Plugins machen, weiss man aber im voraus nicht. Das ist wohl ein ziemlicher Unterschied. Daher habe ich auch nicht von DLLs geredet sondern von Plugins.

Allerdings tendieren meine Gedanken, wie schon gesagt, ebenfalls in diese Richtung, dass ich die Plugin-DLLs wie normale DLLs behandeln soll und es unsinnig ist, da probieren zu wollen, irgendetwas zu schützen. Erst recht nicht den Entwickler vor sich selbst. Aber mich interessieren eben auch andere Meinungen, da ich noch nie ein Plugin-System umgesetzt habe.

Grüssli

hustbaer

Das würde dann meinen Gedankengängen entsprechen, dass es gar keine sinnvolle Isolation geben kann.

Geben kann weiss ich nicht. Man kann in .NET schon Dinge wie AppDomains nutzen um Code halbwegs zu isolieren. Die Frage ist eben wirklich nur ob der Aufwand auch für den Nutzen steht. Da der Nutzen IMO gering ist... -> eher nicht.

Die Frage ist halt, muss ich den Plugin-Entwickler davon abhalten, wenn er probiert über Reflection auf Komponenten des Hauptprogrammes zuzugreifen. Um den Plugin-Entwickler vor sich selbst zu schützen

Programmierer vor sich selbst zu schützen ist so ne Sache. Wenn es a) einfach geht und b) die Chancen sehr gering sind etwas für den Programmierer schwer bis unmöglich zu machen, was er ohne den "Schutz" halbwegs sauber und einfach machen könnte, dann OK. Das ganze private Zeugs dient ja im Prinzip auch nur dafür Programmierer vor sich selbst zu schützen (und gleichzeitig zu dokumentieren was ein Programm nicht macht). Und private finde ich eine gute Sache.
Ich habe allerdings auch schon oft erlebt dass mit der Begründung "Programmierer vor sich selbst schützen" ganz grosser Unfug gebaut wurde.

Dravere

hustbaer schrieb:

Programmierer vor sich selbst zu schützen ist so ne Sache. Wenn es a) einfach geht und b) die Chancen sehr gering sind etwas für den Programmierer schwer bis unmöglich zu machen, was er ohne den "Schutz" halbwegs sauber und einfach machen könnte, dann OK. Das ganze private Zeugs dient ja im Prinzip auch nur dafür Programmierer vor sich selbst zu schützen (und gleichzeitig zu dokumentieren was ein Programm nicht macht). Und private finde ich eine gute Sache.
Ich habe allerdings auch schon oft erlebt dass mit der Begründung "Programmierer vor sich selbst schützen" ganz grosser Unfug gebaut wurde.

Die Sache ist halt, dass es unter .Net MAF (Managed AddIn Framework) und MEF (Managed Extensibility Framework) gibt. Beide sind für Plugins da.
Mit MAF kann man super isolieren, ja sogar die Plugins in eigenen Prozessen laufen lassen. Dafür ist die Kommunikation deutlich schwerer und es muss alles über entsprechende Pipelines gemacht werden, wodurch man komplexe Daten serialisieren muss, um sie auszutauschen. Auch ist der Aufwand um ein Plugin zu schreiben, um einiges höher, wobei man sich auch ein paar Tools zu Hilfe nehmen kann. Grund ist, dass automatisch auch schon eine Versionverwaltung für die Plugins angeboten wird, bzw. für die Schnittstelle. Deshalb müssen jeweils zusätzliche Views und Adapter auf beiden Seiten gebaut werden.
MEF dagegen setzt auf einfache Erweiterbarkeit. MEF ist extrem einfach aufgebaut und mit ein paar Zeilen kann man alle vorhanden Plugins ins eigene Programm laden und zur Auswahl anbieten. Um ein Plugin zu schreiben, muss man einfach vom entsprechenden Interface erben, der Rest erledigt MEF. Es geht sogar soweit, dass man danach mit einem Debugger überall durchkommt. Man kann also das Plugin aus dem Hauptprogramm heraus debuggen. Dafür bietet MEF keinerlei Isolation an und die Daten werden direkt in die AppDomain des Hauptprogrammes geladen. Auch kann man die Plugins nicht mehr "entladen".

Von den Features her tendiere ich eher zu MEF. Da ich allerdings keine Erfahrung bei Plugins habe, habe ich mich gefragt, ob ich vielleicht etwas bei der Isolation nicht sehe, was noch wichtig wäre. Aber bis jetzt scheint dem nicht so zu sein

Grüssli

Gibts keine .net implementierung von osgi ??

hustbaer

Dravere schrieb:

MEF ist extrem einfach aufgebaut und mit ein paar Zeilen kann man alle vorhanden Plugins ins eigene Programm laden und zur Auswahl anbieten. Um ein Plugin zu schreiben, muss man einfach vom entsprechenden Interface erben, der Rest erledigt MEF. Es geht sogar soweit, dass man danach mit einem Debugger überall durchkommt. Man kann also das Plugin aus dem Hauptprogramm heraus debuggen. Dafür bietet MEF keinerlei Isolation an und die Daten werden direkt in die AppDomain des Hauptprogrammes geladen. Auch kann man die Plugins nicht mehr "entladen".

Naja. Dafür braucht man mMn. kein Framework. Klar wird man es verwenden wenn es schon da ist, ein paar hundert Zeilen eigenen Code wird es schon einsparen. Aber viel mehr wohl nicht. Assembly Laden, Typen durchackern und nach "Ich bin ein Plugin" Attribut bzw. dem Plugin-Interface suchen, fertig. Instanzieren über Reflection, verwenden wie jede ganz normale Klasse. Ganz ohne irgendein Framework

Von den Features her tendiere ich eher zu MEF. Da ich allerdings keine Erfahrung bei Plugins habe, habe ich mich gefragt, ob ich vielleicht etwas bei der Isolation nicht sehe, was noch wichtig wäre. Aber bis jetzt scheint dem nicht so zu sein

Wie gesagt: die Frage ist ob man es braucht. Es gibt sicher Anwendungen wo man es braucht, oder wo es sogar vorgeschrieben ist. Angenommen man hat ne wichtige Server-Applikation die einfach laufen muss, und wo ausfälle sehr blöd wären. Da kann es dann schon Sinn machen bestimmte Dinge sogar in eigene Prozesse auszulagern, die idealerweise einfach über Commandline-Parameter, stdin/stdout und vielleicht Files miteinander kommunzieren. Wenn das externe Ding hin und wieder mal crasht sind wenigstens andere Clients und die generelle verfügbarkeit des Service nicht betroffen.

Auch kann es parktisch sein, wenn man mit anderen Firmen oder Abteilungen zusammenarbeitet die sich gegenseitig bekriegen. Wenn dann was passiert und es auf einmal darum geht "wer schuld ist", kann es natürlich praktisch sein, wenn der eigene Code isoliert vom Code von anderen Abteilungen/Firmen läuft. Nach dem Motto "guckst du, andere AppDomain/anderer Prozess, wir könnens nicht sein!".
Wenn die Abteilungen/Firmen etc. zusammenarbeiten wollen ist das aber eher weniger ein Thema.

ps: rück' halt endlich mal raus mit der Sprache: um was für eine Art Anwendung geht es denn nun?

Hey.

Am Besten wäre mMn ein Interface über Lua/whatever. Nur so hast Du die volle Kontrolle (Jenachdem, was Du da schreibst *gg*) über das was passiert, bzw. über die Aktionen und Zugriffe des Anwenders.

Es wäre so sogar noch praktischer. Du hättest ein PRoblem deinerseits beseitigt und Leute, die wirklich was bewirken wollen, können schneller und einfacher Plugins schreiben ohne sich wirklich Gedanken zu machen, wie sie das alles planen (C++ gefrickel, o.Ä.).

Aber ich kann stundenlang auf dir einreden. Die Entscheidung liegt bei dir.
Mach dir doch eine Liste und schreibe Vor- und Nachteile nieder und beachte dabei Anwendung, Nutzen und Beliebtheit (Was sich ja durch Anwendung und Nutzen teilweise reflektiert).

Ich wünsche dir, dass Du rasch auf eine Lösung deines Problems kommst. Plugins, richtig eingebaut, sind schon 'ne feine Sache!

hustbaer

Wenn man Lua auf die einfache Art einbindet (z.B. über LuaInterface), hat man gar keine Kontrolle darüber was passiert oder nicht.

Und wenn man Lua auf die harte Tour einbindet ist das scheisse viel Aufwand und limitiert das was Plugins machen können enorm.

C# DLLs sind eine schöne Sache. Ich wüsste nicht was daran einfacher sein soll ein paar Lua Scripts zu schreiben - da schreib ich lieber eine C# DLL, ehrlich. Intellisense, compiletime Typechecking etc. sind schon eine feine Sache. In Lua dagegen hast du genau *keine* Hilfestellung der IDE. Aber jeder wie er mag.

hustbaer schrieb:

In Lua dagegen hast du genau *keine* Hilfestellung der IDE. Aber jeder wie er mag.

Ähm ja wenn du den code in notepad.exe schreibst natürlich nicht

hustbaer

gasttipp schrieb:

hustbaer schrieb:

In Lua dagegen hast du genau *keine* Hilfestellung der IDE. Aber jeder wie er mag.

Ähm ja wenn du den code in notepad.exe schreibst natürlich nicht

Dann sag mir bitte nen Editor oder eine IDE die da mehr bietet (ausser Syntax-Coloring, was bei Lua eh kaum was bringt).

hustbaer schrieb:

gasttipp schrieb:

hustbaer schrieb:

In Lua dagegen hast du genau *keine* Hilfestellung der IDE. Aber jeder wie er mag.

Ähm ja wenn du den code in notepad.exe schreibst natürlich nicht

Dann sag mir bitte nen Editor oder eine IDE die da mehr bietet (ausser Syntax-Coloring, was bei Lua eh kaum was bringt).

Eclipse, IntelliJ, LuaEdit, decoda, ...

hustbaer

Danke.

Dravere

hustbaer schrieb:

ps: rück' halt endlich mal raus mit der Sprache: um was für eine Art Anwendung geht es denn nun?

Auf wesentliche runtergebracht, könnte man sagen, dass es um eine Backup-Applikation geht. Plugins sollen dazu da sein, Ressourcen zu lesen, um sie abzuspeichern, bzw. auch um zu schreiben, damit man die Backups überall hinsetzen kann, über welches Protokoll auch immer dies funktionieren soll.

~iface schrieb:

Am Besten wäre mMn ein Interface über Lua/whatever. Nur so hast Du die volle Kontrolle (Jenachdem, was Du da schreibst *gg*) über das was passiert, bzw. über die Aktionen und Zugriffe des Anwenders.

Man kann die volle Kontrolle ausüben mit Lua, ja. Aber dann schränkt man die Benutzer meistens sehr stark ein. Ich habe schon Skriptsprachen in verschiedene Applikationen eingebunden, um zum Beispiel gewisse Geschäftslogik dynamisch anpassbar zu machen. Dies kann man aber nur, wenn man die Grenzen des Systems genau ziehen kann. Dies kann ich in meinem aktuellen Fall nicht, weil ich nicht weiss, was der Plugin-Entwickler in der Zukunft genau anbinden möchte.
Sobald man nur etwas von der Kontrolle abrückt in Lua, hat der Plugin-Entwickler die Möglichkeit fast alles zu machen, da kann ich gleich vollständing bei .Net bleiben.

~iface schrieb:

Es wäre so sogar noch praktischer. Du hättest ein PRoblem deinerseits beseitigt und Leute, die wirklich was bewirken wollen, können schneller und einfacher Plugins schreiben ohne sich wirklich Gedanken zu machen, wie sie das alles planen (C++ gefrickel, o.Ä.).

Mit .Net Sprachen kann man verdammt schnell Plugins entwickeln. Zudem hat man noch gleich das ganze .Net Framework zur Verfügung. Bei Lua fehlen dir solche Dinge, bzw. musst sie nachrüsten und das geht nur, wenn man keine Kontrolle ausübt.
Zudem kann man auch in C++ schöne Schnittstellen entwerfen, wodurch es da kein Gefrickel gibt.

~iface schrieb:

Aber ich kann stundenlang auf dir einreden. Die Entscheidung liegt bei dir.
Mach dir doch eine Liste und schreibe Vor- und Nachteile nieder und beachte dabei Anwendung, Nutzen und Beliebtheit (Was sich ja durch Anwendung und Nutzen teilweise reflektiert).

So eine Liste existiert schon längstens. Hier geht es nicht darum, dass jemand für mich eine Entscheidung trifft. Ich will Informationen reinholen, Ideen sammeln, meine Gedanken prüfen.

In den nächsten 5 Wochen wird die Applikation aber sowieso nicht sehr viel weiterkommen, da steht aktuell zu viel anderes Zeug an. In 2 Wochen muss ein Projekt in den Testbetrieb gehen und die Maschinenbau-Abteilung wartet sehnlischt darauf, dass die Heinzelmännchen kommen

Grüssli