Motivation bei Privatprojekten (Split aus Diamond of Death)
-
314159265358979 schrieb:
Ist halt die Frage, wie einfach man dann in anderen Sprachen darauf zugreifen kann.
Äh. GANZ einfach würde ich sagen. stdin/stdout geht überall. Sogar in Brainfuck.
Remote-Plugins scheiden dadurch komplett aus.
Wieso?
Denk mal, wenn das über stdin/stdout geht kannst du auch Shell-Scripts als Plugins bzw. "Wrapper" für Plugins verwenden.
Und wenn wir schon bei Shell-Scripts sind, denk einfach mal an SSH...Edit: Damit könnte ich doch vielleicht auch das Konsolen-Problem des Bots lösen, oder?
Klar könnte man das.
ps: dafür wie wenig du Windows leiden kannst, bist du mit dem "Unix-way-of-doing-it" nicht gerade sehr gut vertraut
ps2: dass ich als "Windows-only" Mensch dir das sage, grenz schon fast an Comdey
-
Plugins würde ich in der ersten Version auf jeden Fall weglassen.
Und dann würde ich über Plugins nachdenken, die durch Hinzufügen einer *.cpp-Datei geschehen. Vielleicht kann man Obervers absetzen? Befehlshandler natürlich. Überhaupt Handler für Nachrichtentypen.
Zu früh würde die Datenschnittstelle die Programmierschnittstelle dominieren, was zielstrebig zur Frickelcode in den Plugins führt, oder?
-
hustbaer schrieb:
Der *NIX-way-of-doing-it wäre einfach stdin/stdout zu verwenden.
Wenn es jedoch mehrere Plugins werden sollen, sind Sockets vom Handling her wesentlich einfacher. Auch kann man dann stdin und stdout für die eigentliche Ein- und Ausgabe aufheben.
-
Stimmt, ich bin mit Unix noch nicht so vertraut. Aber je mehr ich für Unix programmiere, desto lieber mag ich es. Beispielsweise, dass Shared Memory unter Unix Kernel Persistance hat, oder eben dieses "Alles ist eine File" Verhalten. Auch sind die Unix C APIs irgendwie schöner meiner Meinung nach.
Nachdem ich fileno gegoogelt habe, ist mir allerdings etwas lustiges aufgefallen. Unter Linux heißt die Funktione "fileno" http://linux.die.net/man/3/fileno.
Unter Windows gibts sowohl "fileno", als auch "_fileno", wobei bei fileno dabei steht, dass die Funktion deprecated ist, da _fileno mit dem ISO C++ Standard-konform ist. Blöderweise taucht diese Funktion nur nirgens im Standard auf
http://msdn.microsoft.com/en-us/library/zs6wbdhx%28v=vs.80%29.aspx
http://msdn.microsoft.com/en-US/library/ms235401%28v=VS.80%29.aspx
-
314159265358979 schrieb:
Remote-Plugins scheiden dadurch komplett aus.
Nein, tun sie nicht. Wenn du auf Linux arbeitest, kannst du mit einem Programm wie socat die Standardeingabe/Standardausgabe eines beliebigen Programms in ein TCP-Socket verwandeln, und auf dem Ziel-PC dann wieder zurückwandeln in Standardeingabe/Standardausgabe.
Oder du startest ein Plugin remote per ssh, das wär vielleicht einfacher. Dann hättest du stdin/stdout des Plugins auch direkt.
-
ipsec schrieb:
hustbaer schrieb:
Der *NIX-way-of-doing-it wäre einfach stdin/stdout zu verwenden.
Wenn es jedoch mehrere Plugins werden sollen, sind Sockets vom Handling her wesentlich einfacher. Auch kann man dann stdin und stdout für die eigentliche Ein- und Ausgabe aufheben.
Huch?
Ich meine ja nicht stdin/stdout des IRC-Bots, sondern stdin/stdout der Plugins.
Der IRC-Bot spielt dabei sozusagen Shell für die Plugins.
Das ermöglicht zumindest mal mehrere Plugins.Und wenn es ähnlich funktioniert wie unter Windows, dann kann der IRC-Bot Prozess einfach zwei Pipes erzeugen, und diese dem Plugin-Prozess als stdin/stdout unterjubeln. (Kann sein dass unter Linux sogar Sockets gehen als stdin/stdout, SO gut kenn' ich mich in der *NIX Welt nicht aus)
Und da er vermutlich sowieso Boost.Asio verwenden will/wird, wo Sockets/Pipes/... ziemlich gleich verwendet werden können, ist es vom Handling her dann auch nicht komplizierter.
-
hustbaer schrieb:
ipsec schrieb:
hustbaer schrieb:
Der *NIX-way-of-doing-it wäre einfach stdin/stdout zu verwenden.
Wenn es jedoch mehrere Plugins werden sollen, sind Sockets vom Handling her wesentlich einfacher. Auch kann man dann stdin und stdout für die eigentliche Ein- und Ausgabe aufheben.
Huch?
Ich meine ja nicht stdin/stdout des IRC-Bots, sondern stdin/stdout der Plugins.
Ah ok, da gab es ein kleines Missverständnis. So finde ich das auch sinnvoll.
-
volkard schrieb:
Plugins würde ich in der ersten Version auf jeden Fall weglassen.
Und dann würde ich über Plugins nachdenken, die durch Hinzufügen einer *.cpp-Datei geschehen. Vielleicht kann man Obervers absetzen? Befehlshandler natürlich. Überhaupt Handler für Nachrichtentypen.
Zu früh würde die Datenschnittstelle die Programmierschnittstelle dominieren, was zielstrebig zur Frickelcode in den Plugins führt, oder?Plugins sind doch das "eigentliche" Feature des Bots. Der Bot soll ja selbst nichts tun, nur eine einfache Schnittstelle sein. Wieso soll ich denn da die Plugins weglassen?
-
Damits simpler wird und schneller ein Erfolgserlebnis da ist.
-
Mal mein Projektfortschritt:
- Config-Loader fertig
- Logger fertig
- Plugin und Plugin-Manager Klassen fertig
- Socket-Klasse fertig
- Console fertig
- Befehlshandler für Konsole fehlen
- Bot-Klasse, die die einzelnen Teile Koordiniert fehlt
- Plugin API fehltJa, natürlich will ich Aufmerksamkeit, was denn sonst!
-
Sehr gut, weiter so.
-
Sag mal kann es sein das du Aufmerksamkeit brauchst?
-
Ja mit so einem Kiddieprojekt wird bestimmt jeder Mega Respekt haben.
-
top schrieb:
Sag mal kann es sein das du Aufmerksamkeit brauchst?
Natürlich, kannst du nicht lesen?
KennerDerPeinlichen schrieb:
Ja mit so einem Kiddieprojekt wird bestimmt jeder Mega Respekt haben.
Will ich doch hoffen :p
-
Kleine Designfrage.
Ich möchte gerade die console-handler einbauen. Nun ist es so, dass die Klasse 'bot' ein console-Objekt, ein config-Objekt, ein socket-Objekt und ein plugin_manager-Objekt hat. Die Handler werden logischerweise bei der console registriert. Nun braucht man ja von außen auch Zugriff, um diese Handler registrieren zu können. Dafür könnte ich ja eine Funktion machen. Aber die Handler brauchen ja auch Zugriff auf die anderen Komponenten, um z.B. ein Plugin starten zu können. Wie mache ich das am schönsten?
-
Dem Handler beim Aufruf einen Zeiger auf den Bot übergeben?
-
Der Handler wird an dem console-Objekt registriert, welches jedoch den bot selbst nicht kennt. Deshalb funktioniert das nicht.
-
Was handelt so ein Handler denn zum Beispiel?
-
Alles, was der Benutzer in der Konsole eingibt, soll über die Handler geregelt werden. Soll ich vielleicht etwas Code posten?
-
314159265358979 schrieb:
Alles, was der Benutzer in der Konsole eingibt, soll über die Handler geregelt werden.
Wenn der Bot regelmäßig die Konsole pollt und die ihre Handler befragt, also alles synchron geschieht, ist das Übergeben und Weiterreichen des Bot-Zeigers doch kein Problem.
Wenn die Konsole oder der Handler als eigener Thread läuft, oder von einer allgemeinen (vielleicht globalen) onTimer() aufgerufen wird, muß der Handler sich wohl dich einen Zeiger auf den Bot merken. Vielleicht als Konstruktorparameter?
Und man kann sagen, daß im Programm es eh nur einen Bot geben kann und den Zeiger auf ihn global machen.314159265358979 schrieb:
Soll ich vielleicht etwas Code posten?
Nein, den würde ich eh nicht verstehen.