Plugin



  • Hi,

    momentan versuche ich mir ein SDK zum Programmieren von Plugins zu bauen.

    Leider habe ich noch keine richtige Vorstellung davon, wie die Software ein neues Plugin nutzen soll, wenn sie garnicht weiß was das Plugin tut.
    Also es existieren schon Ideen, aber ich habe noch nie ein Beispiel zum Vergleichen gesehen.

    -Ich denke das Plugin müßte ne Anbindung an eine Nachrichtenschleife bekommen.
    Damit kann es mit der Hauptsoftware kommunizieren. Wenn der Pluginprogrammmierer
    die Hauptsoftware kennt, kann er sie somit steuern/benutzen.. oder wie auch immer.

    -Ein weiterer Anwendungsfall wäre, bestimmte Algorithmen aus zu tauschen.
    Zum Beispiel Für die Unterstützung für mehrere Kerne. Die Algorithmenaufrufe
    gehen über ein Interface. Wenn das Plugin installiert ist, werden die
    Aufrufe an das Plugin Delegiert.

    Ich denke eine Idee, wie das Interface von einem Plugin aussehen müßte, würde mir hier weiter helfen.

    Grüße



  • Naja, grundsätzlich zwei verschiedene Dinge wie man mit Plugins arbeiten kann:

    1. Das Plugin gibt bem Programm ein Interface.
      Beispielsweise ein Audio Player kann Plugins zum Lesen/Dekodieren von Audio Files anbieten. Das Plugin muss dabei nie Funktionen des Audio-Players aufrufen, immer nur umgekehrt.

    2. Das Programm gibt dem Plugin ein Interface.
      Das Plugin könnte darüber dann z.B. das Programm steuern, sagen wir ein Fernbedienungs-Plugin für ne Media-Center Software.

    Und natürlich kann man beides kombinieren.



  • Okay,

    Fall zwei ist einleuchtend.

    Aber Punkt Eins --- vorrausgesetzt ich habe das Programm fertig. Jetzt überlege ich mir
    eine neue Funktionalität, welche ich dem Programm durch Plugins hinzufügen möchte.

    Hierfür stellt das Plugin dem Programm ein (neues -- damit meine ich eines mit neuen Funktionsnamen, das könnte der Denkfehler sein) Interface zur Verfügung.

    Was soll das Programm mit den neuen Funktionen anfangen ?? Ich müßte jetzt ja das Hauptprogramm ändern, um die neuen Funktionen aufrufen zu können.

    Egal, wie ich es drehe, ich komme immer wieder zu dem Schluss, dass
    das Interface vom Programm kommen muss... oder nicht ???

    Ich kann mir ein Interface vorstellen, welches vom Programm kommt, und dort verwendet nicht aber implementiert wird. Die implementerung kommt immer von dem Plugin. Das wäre dann dein gedachter Fall Eins ???.

    Mir machen auch Dinge sorgen wie:
    Wenn ich ein bestimmtes Plugin installiere, würde ich eventuell gerne
    die Menüleiste der GUI des Programms verändern.
    Das heißt ich könnte dort auf eine neue Option klicken, welche dann zu einem Funktionsaufruf in dem Plugin führt.
    Das wäre im Gunde genommen ein Anwendungsfall für so eine Kombi aus Fall eins und fall Zwei denke ich.... hmm ja langsam könnts was werden ....



  • Ja, klar, definiert werden muss das Interface immer vom Programm, wenn das Programm damit arbeiten will.

    Du kannst es aber auch ermöglichen, dass Plugins Objekte oder Services mit eigenen Interfaces registrieren.
    Dann kann Plugin A Service X mit Interface X1 registriern, und Plugin B holt sich Service X und verwendet es über das Interface X1.

    A, B, X und X1 müssen dem Programm dabei nicht bekannt sein, das machen die Plugins dann unter sich aus. Das Programm stellt bloss die Funktionen zur Verfügung mittels derer sich die Plugins finden können.



  • Okay, also von der Idee her ist es dann so,
    dass es doch sehr sinnvoll ist, ein eigenes Interface von einem Plugin aus zu definieren.

    Und zwar wenn das Plugin welches das Interface definiert
    von einem oder mehreren Plugins benutzt wird.

    Das heißt eben, dass ich nicht nur die Binaries updaten muss, sondern auch die öffentlichen Interfaces. Hier eben X1.

    Und ich habe Abhängigkeitsgrafen...

    Und Versionskontrolle bräuchte ich auch, um dafür zu sorgen, dass die Plugins auch zueinander passen.

    Das Laden von der Implementierung von X1 müßte dann das benutzende Plugin selber machen. So ist es gedacht oder ??

    Das hört sich nach sehr viel Arbeit an... werd morgenmal die erste Implementierung wargen.



  • In so einem System muss man Interfaces stabil halten, sonst hat man ganz schnell ein furchtbares Durcheinander wo sich keiner mehr auskennt.
    D.h. wenn eine Änderung nötig ist, dann ändert man nicht X1, sondern macht ein neues Interface X2.
    Wenn man die Funktionen in X1 beibehalten kann, dann kann man beide Interfaces parallel anbieten, und alte Plugins die noch X1 verwenden funktionieren noch.
    Wenn man die Funktionen in X1 nichtmehr anbieten kann, dann entfernt man X1, und alte Plugins bekommen einen kontrollierten Fehler. Können also schön eine Meldung anzeigen "uff, kein X1, muss aufgeben".

    Guck dir mal COM an, das ist im Prinzip genau so ein System.



  • Hmmm com scheint mir aber mehr zu sein als Plugins.

    COM automatisiert das Erzeugen eines verteilten Systems oder nicht ???

    Ich weiß noch nicht so richtig, was ich davon halten soll.
    Bin beim Googeln auch auf CORBA gestoßen. Klingt ein bischen nach
    mit Kanonen auf Spatzen schießen.

    Bei COM stört mich, dass es so an Microsoft gebunden scheint/ist.

    EDIT: Gibts denn ne Buchempfehlung zu COM und C++ ??



  • Ich meinte: du solltest dir COM angucken, und evtl. ein paar Libraries die COM nutzen, damit du siehst wie man es machen kann.
    Nicht dass du unbedingt COM nutzen sollst.
    Wäre natürlich auch eine Möglichkeit, aber u.U. nicht die beste.

    COM automatisiert das Erzeugen eines verteilten Systems oder nicht ???

    Nö. DCOM kann Interfaces übers Netzwerk "marshallen". COM ohne D ist nicht viel mehr als ein Haufen Regeln und Standards mit denen man gut Software-Komponenten bauen kann, die man dann in verschiedensten Programmen verwenden kann.



  • AlexanderKiebler schrieb:

    Bei COM stört mich, dass es so an Microsoft gebunden scheint/ist.

    Bei deinem SDK stört mich, dass es so an AlexanderKiebler gebunden scheint/ist.

    Hört doch auf mit dem populistischen "MS bäh". Bringt nichts, und hält nur die Entwicklung auf. Und COM ist genial, da es (man soll es nicht glauben) Plattform-neutral ist. Es ist nur eine Spezifikation, die halt auf Windows implementiert ist. Aber jeder andere kann/darf es auf einem anderem System implementieren. Hatte damals Steve Jobs sogar auf seinem NextStep implementiert, und sogar live DCOM zwischen Windows NT und NextStep Rechnern vorgeführt. Der hatte (wenn ich mich richtig erinnere) in einem Excel-Dokument (in NT) Daten von einer NextStep-Maschine aus manipuliert.



  • Hi,

    also das sollte jetzt keine abfällige Bemerkung über COM sein.
    Ich weiß schon das es plattformunabhängig ist, so war das nicht gemeint.
    EDIT: Okay, das mit der plattformunabhängigkeit ist wohl eher eine Streitfrage.
    Spezifikation<->Implementierung schetze ich

    Aber es gibt gewisse Dinge die ich miteinander in Verbindung bringe.
    Z.B. Eis <-> klat, lecker, süß, schokolade, himbeere, banane, zitrone , nuss, jogurt *lach*

    Nur weil ich weiß wie lecker zitrone ist, mag ich wohl Jogurt nicht so. =)...

    und Microsoft <-> COM und das wars.

    Ich hätte wohl eher sagen müssen mir fehlt ein zweites Beispiel. Das hat nichts mit der Firma zu tuen oder mit com an sich.


Anmelden zum Antworten