Modularer (evtl. verteilter) Programmaufbau - Welche Art von IPC ist die richtige?

[Der schöne Günther]

Es gruselt mich hier nur etwas davor, überall noch Copyright 2003 zu lesen. Die von alphaflight83 freundlicherweise zur Verfügung gestellte Anpassung an Unicode und ähnliches kann ich auf die Schnelle bei mir kompilieren, habe es aber noch nicht wirklich getestet.

Im Endeffekt ist es ja eigentlich ziemlich genau, was mir vorschwebt. Es ist nur so ... alt ... und einsam.

[sh17]

das ist doch das hier? http://sourceforge.net/projects/delphixml-rpc/
da gibts auch nen Branch-Zweig im Quelltext.

Was soll sich an XML-RPC auch ändern, außer die Lauffähigkeit unter Delphi höherer Versionen. Geht ja alles.

[Der schöne Günther]

Ja, ändern muss sich daran eigentlich schon lange nichts mehr.

Nur entweder hat mein Gehirn in den letzten Jahren stark abgebaut, oder SourceForge wird auch nicht übersichtlicher. Ich finde nur irgendeinen "Branch 3.0" aus 2009, der nichts weiter als eine Kopie der 2003er-Version ist.

Die hier im Forum gepostete Aktualisierung auf Unicode bekomme ich wenigstens zum Laufen.


Ich fürchte mich nur davor, dass ich darüber sonst nicht viel finde, außer ein paar noch halb funktionierende Webseiten von vor zehn Jahren. Habe ich so ein exotisches Anwendungsszenario? Was macht die Welt sonst? Riesige Middleware lizensieren und gut ist?

[sh17]

Zitat von Der schöne Günther:

Ich fürchte mich nur davor, dass ich darüber sonst nicht viel finde, außer ein paar noch halb funktionierende Webseiten von vor zehn Jahren. Habe ich so ein exotisches Anwendungsszenario? Was macht die Welt sonst? Riesige Middleware lizensieren und gut ist?

Kann ich verstehen, dann müsstest Du Dich aber auch vor dem selbst programmieren fürchten, weil Du evtl zuviel Zeit benötigst und sich vielleicht Probleme auftun, die Du jetzt noch nicht erkennst.

Wovor hast Du mehr Angst:

1 etwas altes anpassen, das es für dich reicht und funktioniert
2 etwas komplett neues bauen, das es für dich reicht und funktioniert
3 etwas neues für Kohle erwerben, was den neuesten Hype implementiert, eigentlich eine Kanone auf deinen Spatz ist, aber es funktioniert.

wie sagt man: "gehen muss es"

Ich würde 1. nehmen, wenns nicht klappt, 3.

[Der schöne Günther]

Das führt es mir noch einmal richtig deutlich vor Augen, danke dafür!

Meine persönliche Präferenzen sehen (und sahen) nämlich anders aus: 2-3-1. Ich bin bislang eigentlich immer besser damit gefahren, selbst etwas aus dem Boden zu stampfen und keine Zeit über 20 Minuten darauf zu verschwenden, mir überhaupt einen Überblick über das zu verschaffen, was schon geht. So bin ich halt.

Fallen später Erweiterungen an, weiß ich genau, wie mein Kram funktioniert und setze es um. Gerade bei (1) wird mir hier unwohl - Ich kenne den Untergrund nicht wirklich und es gibt keine Community mehr. Bei (3) hat man bei einem modernen Produkt eine Wahrscheinlichkeit, dass das ein gewünschtes Anwendungszenario sowieso schon enthalten oder berücksichtigt ist und man kann sich mit anderen Leuten darüber austauschen.

[sh17]

um zwischen 1,2 und 3 zu unterscheiden, würde ich auf jeden Fall den finanziellen/zeitlichen Anteil in Betracht ziehen. (Zumindest bei solch komplexen Sachen, jeden kleinen Mist kauf ich nicht zu, da tendiere ich auf jeden Fall zu selbst machen)

- Wie lange brauche ich, um es selbst zu implementieren - Zeit - Geld? Beispielsweise 2-3 Wochen?
- Was kostet das entsprechende Gegenstück und der gedachte Einarbeitungsaufwand? Beispielsweise um die 500 EUR Lizenz + 1 Woche.

Im Beispiel wäre ich jetzt schon für die kommerzielle Lösung, wenn ich pro Std von 100 EUR ausgehe.

Wenn das noch nicht reicht als Überzeugung:

- Kann ich die zugekaufte Lösung im Extremfall dann doch durch eine eigene Lösung relativ einfach ersetzen? D.h. drückt mit die kommerzielle Lösung kein Schema auf.

[Der schöne Günther]

Ja, ich werde mich in dieser Woche darüber besprechen. Im Endeffekt bin ich nicht derjenige, der über Zeit und Geld entscheidet. Zeitdruck herrscht (wie immer) auch, zumindest für eine grobe funktionierende Vorabversion.

Mittlerweile kann ich zum Thema überhaupt etwas sagen, ich bin sehr gespannt, wohin die Reise letztendlich gehen wird. Das Thema hat mir wirklich großartig weitergeholfen, noch einmal vielen Dank an alle!


PS: Gargano hier im Forum war vor ein paar Jahren wohl in genau der gleichen Situation wie ich...

[mjustin]

Zitat von Der schöne Günther:

Habe ich so ein exotisches Anwendungsszenario? Was macht die Welt sonst? Riesige Middleware lizensieren und gut ist?

Vermutlich wird die Welt für kleinere EInsatzgebiete etwas wie MsgConnect einsetzen:

* MsgConnect is a cross-platform protocol-independent communication framework designed to simplify the task of building peer-to-peer and client-server applications and middleware components. (wenn man sich die Wunschliste unter "Most wanted Features" ansieht fehlen aber einige Features eines modernen Message Brokers).

Ich entwickle zwar auch selbst kommerzielle Messaging Middleware Clients für Delphi, aber die damit einzusetzenden Server benötigen Java oder Erlang als Runtime, was möglicherweise nicht gewünscht wird.

[Der schöne Günther]

Hallo-

Ich habe mich jetzt noch einmal besprochen und es wird in meinem Fall nicht auf ein (großes) Middleware-Framework hinauslaufen - Es ist (und wird wohl auch nie) ein "echtes" verteiltes System werden: Einfache Datenvisualisierung auf irgendeinem anderen PC wäre vielleicht ganz nett, aber nichts was momentan wirklich interessiert. Im Endeffekt bleibt es immer bei einer zentralen Maschine im Schaltschrank die ab und an mal bedient wird und selbstständig Reports und Messwerte weiterschickt oder in Kunden-Datenbanken abspeichert.

Insgesamt werden also deutlich kleinere Brötchen gebacken, es wird wohl eine stinknormale Windows-IPC-Methode (wie Sockets oder Named Pipes) mit einer im Endeffekt beliebigen Formatierung (wenn ich genug Zeit habe, versuche ich irgendeinen Standard wie XML-RPC einzuhalten). Der Grund ist auch, dass man in diesem Umfeld niemanden beeindrucken kann, eine voll serviceorientierte Architektur bereitzuhalten - Hier ist so viel Paranoia im Spiel, da erreicht man damit eher das Gegenteil

Weiterhin werden auf alle Ewigkeit wohl sowohl Kern als auch alle Module von den gleichen Leuten implementiert und betreut werden. Deshalb ist es halb so wild.


Insgesamt ein tolles und für mich ungewohntes Thema, ich habe in den letzten Tagen viel gelernt
und produktiv nichts geschafft