Wie funktionieren Plugins?
-
Hi.
Ich bin kein sehr erfahrener Programmierer, aber will schon seit langem wissen, wie Plugins funktionieren, besonders am Beispiel von Mozilla.
Ich stelle mir dabei ein versimpeltes Framework vor, was der Entwickler der Software den Pluginentwicklern zur Verfügung stellt, damit diese sich schnell einarbeiten. Z.B. dass das Framework Variabeln wie Browserhintergrundfarbe oder Standardschriftgröße bestimmt. Wenn die Plugins dann aktiviert werden, dann initialisiert die Muttersoftware sich erstmal selbst, um anschließend Initialisierungen von den Plugins drüber schreiben zu lassen, damit die Einstellungen der Plugins nicht verwirkt werden. Plugins haben somit eine gewisse Priorität. Stelle ich mir das so richtig vor?
Dann fragte ich mich noch, ob es sinnvoll ist jede Funktion als Plugin einzubauen, um Performance zu steigern. Es wird nur noch geladen, was der User wirklich braucht. Aus einem LibreOffice oder MS Word könnte man so einen leichtgewichtigen Editor machen, den man über Plugins dann wunderbar anpassen kann. Wär das sinnvoll?
MfG
-
Guck einfach mal nach composite patterns.
Oft gibt es dafür Framesworks, bei Wpf und Silverlight
heißt es zb. Prism.Man baut beispielsweise nur eine Rahmenanwendung und definiert regionen,
in denen sich Module darstellen können. Die Module werden dann beim
starten geladen und in den entsprechenden regionen dargestellt.Programmiertechnisch wird hier hauptsächlich mit interfaces und
Dependency Injections gearbeitet.Die Module liegen zb in einem verzeichnis oder in Datenbank.
Man könnte module auch Benutzerspezifisch laden.Hauptaufgabe des Frameworks ist es die module einzulesen
und die Funktionen des Modules bereit zu stellen.
-
Linux_Rules schrieb:
Stelle ich mir das so richtig vor?
Nee
Linux_Rules schrieb:
Wär das sinnvoll?
Nee
Du hast irgendwie sehr abstrakte Vorstellungen davon und ich weiß nicht, was du jetzt eigentlich zu hören erwartest. Technisch gesehen sind Plugins nichts besonderes. Die konkrete Implementierung hängt von der Programmiersprache und Technik ab. Im Endeffekt definiert man Schnittstellen, die entweder vom Plugin implementiert werden müssen oder vom System bereitgestellt werden.
Einen leichtgewichtigen Editor statt Libre Office kriegst du so sicher nicht hin. Je mehr Pluginschnittstellen du definierst, desto komplexer wird der Integrationscode und irgendwann steigt die Komplexität exponentiell. Und die Benutzer wollen diese Komplexität sicher auch nicht haben. Immer dieses Geschwätz von "überflüssigen Funktionen" und "leichtgewichtiger Software". MS Office oder Libre Office ist in paar Sekunden gestartet, und die Funktionen, die ich nicht brauche, stören mich nicht. Dafür gibt es aber mehrere hundert anderer Anwender, die vielleicht andere Anforderungen haben, als ich, und diese Funktionen brauchen. Und wenn ich mal doch eine etwas ausgefallenere Funktion brauche, google ich kurz wie es geht und benutze es einfach. Jetzt stell dir vor, es würde tausende von Plugins geben, die man sich zusammensuchen und installieren muss, die sich gegenseitig stören usw. Und dann verschickst du ein Dokument und der Empfänger kanns nicht aufmachen, weil er erstmal 50 Plugins nachinstallieren muss. Natürlich wär die Software danach kein Stück "leichtgewichtiger", kann ja nur länger dauern, Plugins zu laden und zu registrieren.
Das soll jetzt kein generelles Statement gegen Plugins sein, sie sind natürlich sehr sinnvoll, auch in Office Paketen. Aber nicht in der Hinsicht, dass man ein schlankes Basisystem definiert und alles andere Plugins sind.Linux_Rules schrieb:
Ich stelle mir dabei ein versimpeltes Framework vor, was der Entwickler der Software den Pluginentwicklern zur Verfügung stellt, damit diese sich schnell einarbeiten.
Find ich lustig. Ob das simpel ist, oder sich jemand schnell einarbeiten kann, spielt meist überhaupt keine Rolle. Ich sag mal nichts zu Mozilla, find das Beispiel uninteressant. Aber ich hab schon viel mit Schnittstellen von CAD und ERP Systemen gearbeitet, und die sind oft Lichtjahre davon entfernt, einfach, verständlich, oder gut dokumentiert zu sein.
-
Mechanics schrieb:
Das soll jetzt kein generelles Statement gegen Plugins sein, sie sind natürlich sehr sinnvoll, auch in Office Paketen. Aber nicht in der Hinsicht, dass man ein schlankes Basisystem definiert und alles andere Plugins sind.
Das ist doch aber genau das was zum Beispiel eclipse macht (rich client platform). So unsinnig kanns also nicht sein.
Sowas wie "simpel" ist natürlich auch im Kontext zur Problemstellung zu sehen. Stell dir vor du müßtest deine CAD-Problemstellung stand-alone lösen. Wär das nicht viel schwieriger?
-
Mechanics schrieb:
Jetzt stell dir vor, es würde tausende von Plugins geben, die man sich zusammensuchen und installieren muss
Alternaties Modell: jeder user besitzt eine große Zahl von Plugins, aber die Software lädt die dynamisch nach, je nachdem was das Dokument braucht. Dann dauert zwar das Laden des Dokuments länger, aber die Software startet komplett ohne Verzögerung. Das lässt sich sicher noch mit einem System kombinieren, das die X meistgenutzten Plugins des Users automatisch mit lädt.
-
otze_logout schrieb:
Dann dauert zwar das Laden des Dokuments länger, aber die Software startet komplett ohne Verzögerung.
je öfter ich des les, desto unsinniger wirds
-
Jester schrieb:
Das ist doch aber genau das was zum Beispiel eclipse macht (rich client platform). So unsinnig kanns also nicht sein.
Schlechtes Beispiel. Was ist an Eclipse schlank oder leichtgewichtig? Das ist ein Monstrum, braucht ewig zum Laden, braucht sehr viel RAM und ist lahm ohne Ende. Und funktiniert nicht richtig. Ich weiß, viele Leute arbeiten mit Eclipse und paar sind sogar zufrieden. Aber es gibt sehr viele Probleme damit, und viele sind auch auf diese Architektur zurückzuführen. Und das System ist komplett undurchsichtig und nicht wartbar. Ich werde garantiert nie wieder freiwillig damit arbeiten.
-
bing bong der king kong schrieb:
otze_logout schrieb:
Dann dauert zwar das Laden des Dokuments länger, aber die Software startet komplett ohne Verzögerung.
je öfter ich des les, desto unsinniger wirds
Zum einen das, zum anderen erinnert mich das irgendwie an Tex und ctan. Das will ich sicher keinem Endbenutzer zutrauen.
-
Die Addons von Firefox können auch in Javascript geschrieben werden. Es gibt dann einfach zusätzlich Funktionen und Variablen, die man ansprechen kann. So kommuniziert man dann mit der Anwendung und verändert ihr Verhalten.
-
Mechanics schrieb:
Jester schrieb:
Das ist doch aber genau das was zum Beispiel eclipse macht (rich client platform). So unsinnig kanns also nicht sein.
Schlechtes Beispiel. Was ist an Eclipse schlank oder leichtgewichtig? Das ist ein Monstrum, braucht ewig zum Laden, braucht sehr viel RAM und ist lahm ohne Ende. Und funktiniert nicht richtig. Ich weiß, viele Leute arbeiten mit Eclipse und paar sind sogar zufrieden. Aber es gibt sehr viele Probleme damit, und viele sind auch auf diese Architektur zurückzuführen. Und das System ist komplett undurchsichtig und nicht wartbar. Ich werde garantiert nie wieder freiwillig damit arbeiten.
FULL ACK.
Leider muss ich damit arbeiten, da verschiedene Hersteller Eclipse als Basis für ihre IDE nehmen. Ich habe allerdings noch von keinem Hersteller eine stabile und schnelle Version erlebt. Im allgemeinen muss man warten und zig Workarounds erlernen, damit man damit einigermasen vernünftig arbeiten kann.
Das Problem von Plugin-Schnittstellen ist, dass sie sehr allgemein gehalten werden müssen. Es kann keinerlei Optimierungen über die Schnittstelle hinein passieren. Dadurch entstehen z.B. mehrfache Initialisierungen von gleichen Inhalten. Ein Lazy-Loading ist auch ohne die Verwendung von Plugins möglich. Wenn die Funktionalität bekannt ist, kann so ein Lazy-Loading optimiert und für die Anwendung zugeschnitten durchgeführt werden.
Grüssli
-
bing bong der king kong schrieb:
otze_logout schrieb:
Dann dauert zwar das Laden des Dokuments länger, aber die Software startet komplett ohne Verzögerung.
je öfter ich des les, desto unsinniger wirds
100% aller dokumente starten als leeres "neues dokument".
-
Ich denke das Beispiel ist prima.
