INVESTOX-Forum

Hallo Frank

Das hört sich nach einer guten Idee an.

Nachdem ich mir die Einschränkungen von C2's eMail Schnittstelle angesehen habe, halte die 2. Variante für besser geeignet: ein eMail Server im eigenen LAN, der die eMails von Investox empfängt, konvertiert und sie im normalen API-Mode an C2 sendet. Was mir auf die Schnelle noch nicht klar ist: kann Investox alle für das C2-API relevanten Informationen liefern, oder muss auch hier von Seiten Herrn Knöpfels etwas getan werden?

Hallo

Hier habe ich die Sourcen zu einem SMTP Dummy Server gefunden (in VB geschrieben; müsste sich sogar mit der kostenlosen VB Express Edition von MS weiterentwickeln lassen!).

Dieser Server scheint mir als Ausgangspunkt recht gut geeignet:
* er ist eigentlich als Testprogramm dazu gedacht, auf einem Rechner im LAN zu laufen für Leute, die Programme mit Mailversand-Features entwickeln
* so wie ich es verstanden habe, schreibt das Programm ein empfangenes Mail in eine Text-Datei, einfach damit man es für Testzweck ansehen kann

Da wäre also schonmal ein solider Rahmen vorhanden! Statt dem Schreiben in eine Text-Datei müsste man nun das Mail von Investox
* auf das API von C2 routen
* wenn gewünscht zusätzlich an einen normalen Mail-Account weiterschicken

Vielleicht spricht jemand die Programmierung der nötigen Funktionen generell oder als Einstieg in die Programmierung an.

Hallo Frank

Heute habe ich mir mal ein eMail Signal schicken lassen von Investox. Das sieht so aus:

Zitat

Projekt: burst_mixed_multiday_10_PT
Titel: Russel2000_eM_cont_1Min
WKN: Rus2k_eM_cnt1m
System: 40_Russel
Datum/Uhrzeit: 19.05.2008 20:00:00
Signal: Enter Short
Basiskurs: 743.0
Stückzahl: 1
Investition: 10'000.00
Verluststop: K/A
Gewinnstop: K/A

Demgegenüber wurden folgende Order ausgeführt (siehe Bild).

Man sieht auf den ersten Blick, dass die per eMail gelieferten Daten völlig unbrauchbar sind, um daraus eine eMail -> C2 Schnittstelle zu basteln!


Herr Knöpfel

Wäre es nicht bitte möglich, zu einer Investox Anbindung an C2 eine Aussage zu treffen! Ausserdem wäre es hohe Zeit für eine geeignete API Schnitstelle, die alle Order zeitgemäss und vollständig zur Verfügung stellt; ein erster Schritt, um Investox endlich einmal für die Aussenwelt zu öffnen!

Was für den Inbound gilt ...

Zitat von »bernd«

proprietäre Speicherformate machen keinem Freude. Überlassen Sie es doch bitte dem Anwender, wie er die Daten für einen Import bereitstellt. XML wäre ein tolles Format

... gilt eben auch Outbound.

Hallo,

grundsätzlich wäre der Schritt in Richtung XML gut, da XML für jede Form des Austausches von Informationen DER technische Standard geworden ist. Selbst die Kommunikation mit uralten Hostprogrammen erfolgt heute schon oft per XML.

Aber, XML ist eigentlich nichts anderes als csv oder ein sonstiges Format für den Austausch von. Ein Vorteil ist, dass die Attribute nach festen Regeln selbstbeschreibend sind - zumindest wenn das Format nicht von einem Stümper festgelegt wurde der Die Attribute etwas "Attribut1" oder so benennt.

Und genau dort ist der Hacken von XML. XML ist nicht wirklich etwas Neues. Wenn ein XML schlechte Strukturen hat ist es zu nichts zu gebrauchen. Für die meisten ist der wesentliche Vorteil der, dass es Mode ist für Programmierer ist der Vorteil, dass es mittlerweite in quasi allen Sprachen sehr einfach ist XML zu erzeugen und zu parsen.

Die Struktur, also der Aufbau des Inhalts und die übergreifende Akzeptanz erst sorgen für Offenheit. Und daran hapert es zum Beispiel sehr oft auch noch im industriellen Bereich.

Über das neue VB haben wir jetzt ja die Möglichkeit selber XML-Schnittstellen zu bauen und zu verwenden. Auch für VBScript gibt es XML-Parser. Mich würde mal interessieren, wer sich bisher mit einem solchen Ansatz beschäftigt hat.

Viele Grüße

Martin

Hallo Frank,

nichts einfacher als das.

Man könnte die Signale in beide Richtungen, also auch zum Beispiel für den Import Collective 2 (wenn die XML unterstützen, ein- und auslesen.

Dabei wäre man nicht allein auf eine Auswertung von XML-Dateien beschränkt. Genauso könnte man Investox auf diese Weise WebService-enablen. In diesem Fall würden die Signale als Webservice von anderen Quellen übernommen oder man würde einen Service für andere Abnehmer schaffen.

Viele Grüße

Martin

Hallo Martin

Zitat von »Cash«

Du meinst, man könnte z.B. eine art Indikator in VB programmieren, der bei Handelssignalen XML Daten generiert

Zitat von »MartinP«

nichts einfacher als das.

Ich ziehe meinen Hut. Wenn das so einfach ist, mach doch mal. Natürlich unter Berücksichtigung der ORM Einstellungen, bitte.

Hallo Bernd,

technisch ist es keine besondere Herausforderung ... aber fachlich!

Technisch kann man Investox mit vertretbarem Aufwand um Spielereien wie Webserevices (Server oder Consumer) ergänzen. Die eigentliche Schwierigkeit liegt aber in der Definition der Dienste. Daher ziehe ich meinen Hut vor Herrn Knöpfel, der ein fachliche super funktionierendes System erstellt hat und Aspekte wie ORM sauber berücksichtigt hat.

Und jede ach so hoch gepriesene Technik taugt nur im richtigen Anwendungsfall was.

Da der mir aber so nicht einfällt, lasse ich die Finger davon. Programmieren ist kein Selbstzweck.

Herzliche Grüße

Martin

Hallo Martin

Zitat von »MartinP«

Die eigentliche Schwierigkeit liegt aber in der Definition der Dienste. Daher ziehe ich meinen Hut vor Herrn Knöpfel, der ein fachliche super funktionierendes System

Das ist ja alles gut und schön und ich bin auch von Investox begeistert.

Als Plattform ist es ein guter Ausgankspunkt - aber Tasache ist, Herr Knöpfel ist eine One-Man Show, und es geht zu langsam voran.

Es gibt so viele offene Themen, angefangen vom ziemlich suboptimalen Formel-Editor über vernünftige Fehlermeldungen und diese lästige Recompilierungs-Problematik bei neuen Investox Versionen (ich denke, gerade Du weisst, was ich meine) bis hin eben zu solchen Inbound und Outbound Problematiken. Weil alles proprietär gelöstst, kann man von aussen auch nichts Gescheites an Investox dranprogrammieren.

Bei allen Verdiensten von Herrn Knöpfel, das gefällt mir einfach gar nicht, und die fehlenden Teile werden auch viel zu langsam ergänzt. Und wegen dem durch und durch proprietären Ansatz kann man ihm auch nicht wirklich helfen. Er müsste einfach selber schneller vorwärts machen.

Hallo Bernd,

das Problem mit Investox wie mit fast jeder anderen "guten" und seit vielen Versionen verbesserten Software ist, dass die Erweiterungen draufgesetzt werden und die technische Architektur des Systems nicht mehr wirklich passt. Erweiterungen werden dann schwieriger und führen zu unnötigen Performanceproblemen.

Aber einerseits ist der Markt für Handelsplattformen nicht so groß - wenn man von den internen Entwicklungen in Banken und Investmenthäusern absieht - und es wäre ein großer Zufall, wenn sich Fachwissen über den Handel, Vision über die neue Verwendungen der Plattform und tiefgehendes technsiches Know-How treffen.

Herr Knöpfel hat die ersten beiden Punkte mit Investox m.E.n. gut gemeistert. Bei der Technik hat er eine für seine Zeit sehr übliche Entscheidung getroffen. Und ob er sich bei der Entwicklung von vornherein den Luxus einer erweiterbaren Architektur gegönnt hat kann ich nicht sagen. Vom ersten Wurf einer neuen Software bereits Offenheit, Erweiterbarkeit und Performance in einer sauberen Architektur zu berücksichtigen und diese über ein Refactoring auch zu halten ist schwer und beim Start zumeist kostspielig.

Wenn du aber ein paar gute Ideen hast können wir uns gern mal austauschen.

Herzliche Grüße

Martin