Client/Server vs standalone

Hi.

Ich überlege, ob es sinnvoll ist, wenn ich meine Programme in Zukunft als Client/Serverlösung programmiere, statt standalone, auch wenn dies nicht unbedingt nötig ist. Durch die Sockets, kann man mit dem Programm von außen während der Laufzeit kommunizieren und man hat viele Netzwerktools zur Verfügung.

Bei einer standalonelösung finde ich es problemantischer, wenn man das Programm anpassen möchte, weil Daten nur in Zwischenspeichern liegen. Beim Client/Servermodell jedoch wird alles vorher schön geordnet durch das Netzwerk geschickt und kann simpel manipuliert werden. Z.B. wenn man ein Texteditor hat, so könnte man diesen in Client und Sever spalten, wobei dann der Client für das Schreiben verantwortlich ist und der Server für das Speichern. Wenn nun eine Person gerne einige Worte ersetzt haben will, könnte er die Daten durch einen Proxy schicken und die Daten manipulieren, wie er wünscht, ohne dass er sich in den Quellcode einarbeiten muss, um die Funktion extra hineinzuschreiben.

Was denkt ihr von dieser Lösung?

MfG

Eisflamme

Ich finde, für Client/Server sollte es eine plausible Erklärung geben. Ich sehe in Deinem Beispiel nicht wirklich den Vorteil. Der große Nachteil ist jedoch, dass alles langsamer wird, dass man ans Internet angebunden sein muss, dass bei Serverabbruch ein einfacher Texteditor nicht mehr funktioniert, ganz abgesehen von den Problemen im Bezug auf Datenschutz/Datensicherheit... ich mag so was nicht.

Eine Umsetzung ist ja z.B. GoogleDocs. Da geht es natürlich um Kollaboration, daher hat das seine Existenzberechtigung, aber wenn ich dort Mal etwas hinschreiben werde, nervt mich die Verzögerung und das gelegentliche Abbrechen schon enorm.

Um also herauszufinden, ob Client/Server angemessen ist, musst Du schon einen genaueren Anwendungsfall aufzeigen.

Ich finde die Idee nur gut, weil das Programm dadurch sehr "extrovertiert" ist, wodurch eine Community halt sehr simpel Addons bauen kann. Bzw. einfach nur existierende Programme konfigurieren muss, wie der erwähnte Proxy. Dadurch spar ich mir ja als Entwickler viel Zeit.

Übrigens dachte ich eher daran, den Server auf dem selben Rechner, wie den Client laufen zu lassen ohne Internet.

hustbaer

@Net Game
Für den von dir erwähnten Fall würde ich eher ein einfaches Plugin-Interface anbieten, mit dem man z.B. "VFS" (Virtual File System) Plugins einhängen kann.
Den Umweg über TCP/IP halte ich für Sinnlos.

Gibt es eigentlich noch andere Lösungen, um auf den Datenstrom eines Programmes zu zugreifen?

hustbaer

Wenn du eine einnvolle Antwort möchtest musst du erstmal "Datenstrom eines Programms" genauer definieren.

Mit Datenstrom meine ich die Daten, die vom User eingegeben werden und die vom Programm ausgegeben werden, z.B. auf dem Monitor.

Mal als ernstgemeinte Frage: Hast Du überhaupt schonmal irgendwas programmiert? wenn ja, in welcher Sprache?

Das wirkt auf mich wie ein Blinder der die Malerei revoluzionieren will...

Ja, ich programmiere. Aber ich bin kein Pro. Trotzdem habe ich viele Ideen und will sie alle austesten. Im besten Fall könnte es sogar eine Revolution werden.

knivil

Ansatz ist alt und hat sich als nicht praktisch erwiesen. Das mag sich im Hinblick auf Cloudservices aendern. Dort bleibt einem keine andere Wahl. Kein Texteditor ist so gestrick. Selbst finde ich ihn auch wenig praktisch. Die Netzwerkschicht im konkreten Fall finde ich unnoetig und birgt zusaetzliche Fehlerquellen. Sie erhoet nur unnoetig die Komplexitaet und bringt keinen Mehrwert.

Allesquatsch

knivil schrieb:

Ansatz ist alt und hat sich als nicht praktisch erwiesen.

Uff. Da fährst Du aber schweres Geschütz auf. Denn es gibt eine Menge Anwendungsbereiche, die quasi nur darauf basieren, dass sich diverse Instanzen gegenseitig (lesbare) Nachrichten schicken. Selbst innerhalb von großen Anwendungen ist dieses Prinzip noch State-of-the-Art, z.B. bei ERP. In weiten Teilen des industriellen IT-Einsatzes hat sich das seit über 30 Jahren bewährt und wird voraussichtlich auch noch lange bleiben.
Die Tendenz hat sich noch verstärkt, da Speicherplatz und Bandbreite heute leichter verfügbar sind als Entwickler.

Das Problem mag eher in der noch pauschaleren Fragestellung liegen. Die liegt eher auf dem Niveau, ob der Hammer das geeignete Werkzeug für Heimwerker sei.
Und dann denkt der eine an Innenausbau, der zweite ans Fliesenlegen, der dritte ans Tapezieren und der vierte an Elektroinstallation.

Liegt aber wahrscheinlich an der fehlenden Praxis des Fragestellers und nicht an Dummheit. Denn das man eine solche Frage stellt, zeugt davon dass man über die Eignung nachdenkt und nicht mit irgendwelchen "Java rulez"-Sprüchen auftritt.

Ciao, Allesquatsch

knivil

diverse Instanzen gegenseitig (lesbare) Nachrichten schicken

"Lesbare Nachrichten ueber Netzwerk" ... ist was anderes als nur Nachrichten. Und wer XML-Dateien als lesbar bezeicht, dem kann ich ja mal ein Buch in XML schicken.

In weiten Teilen des industriellen IT-Einsatzes hat sich das seit über 30 Jahren bewährt und wird voraussichtlich auch noch lange bleiben.

Ich rede aber von dem konkreten Fall Texteditor, also einer Anwendung wie Notepad. Ich rede nicht von Unix-Sockets, Corba oder Java RMI.

Allesquatsch

Ich rede aber von dem konkreten Fall Texteditor, also einer Anwendung wie Notepad. Ich rede nicht von Unix-Sockets, Corba oder Java RMI.

Tatsächlich war es vor zwanzig Jahren noch üblich, auf dem Großrechner mit dem Editor oder Browser an solche Sachen zu gehen. War damals natürlich kein XML sondern einfach spaltenweise organisierter Text. Wegen von der Lochkarte ererbten Standards waren die Zeilen auf 80 oder 132 Spalten begrenzt.
Lustigerweise liegen bei vielen ERP-System hinter der gewöhnlichen PC-Oberfläche immer noch diese Message-Queues. Und gibt's mal Verstopfung wird die Bitflinte ausgepackt.

Ciao, Allesquatsch

Das ist hochinteressant. Hat dieses Client/Servermodell bzgl. dieses Themas noch einen genaueren Namen? Und eigentlich müsste das doch auch peer to peer funktionieren?

Mir fehlt es wirklich an der Praxis. Ich bin eigentlich nur Manager.

Wie gesagt, das Konzept wollte ich nicht nur auf Texteditoren anwenden. Ich will sowas ähnliches bezwecken, wie dbus unter Linux. Das ist auch so eine Client/Server Struktur, mit der Programme untereinander kommunizieren können.

Allesquatsch

Net Game schrieb:

Mir fehlt es wirklich an der Praxis. Ich bin eigentlich nur Manager.

Erinnert mich an Dilberts Chef.

http://search.dilbert.com/comic/Database Color

(Uff, 1995. Ich bin immer wieder verwundert, was einem so im Hirn hängen bleibt.)

Üblicherweise ist es geschickter, wenn sich Entwickler um die technische Umsetzung und Manager um die fachlichen Anforderungen kümmern.

Ciao, Allesquatsch

Interprozesskommunikation (IPC) nennt sich meine Idee und ist unter Unix tatsächlich nahe zu Standard. Unixgurus empfehlen es sogar. Ob das Programm nun Unix Sockets (=IPC Sockets), Pipes oder TCP Sockets nutzt, ist nicht so extrem wichtig, wobei Pipes und TCP Sockets wegen Flexibilität empfohlen werden.

Mich als blinder Maler bezeichnen zu lassen, wenn ich als "blosser" Manager Ideen, wie die Unixentwickler selbst habe, ist schon ziemlich derbe.

Net Game schrieb:

Interprozesskommunikation (IPC) nennt sich meine Idee und ist unter Unix tatsächlich nahe zu Standard. Unixgurus empfehlen es sogar. Ob das Programm nun Unix Sockets (=IPC Sockets), Pipes oder TCP Sockets nutzt, ist nicht so extrem wichtig, wobei Pipes und TCP Sockets wegen Flexibilität empfohlen werden.

Mich als blinder Maler bezeichnen zu lassen, wenn ich als "blosser" Manager Ideen, wie die Unixentwickler selbst habe, ist schon ziemlich derbe.

Also das klingt schon sehr nach Dilbert. IPC sagt einfach, dass verschiedene Prozesse Daten austauschen können. Und Unixgurus sollen empfehlen, dass Prozesse Daten austauschen sollen .

Ich als Manager in der Autoindustrie empfehle, dass das neue Auto Räder haben sollte. Die Ingenieure empfehlen das auch.

Das ganze klingt professionell für diejenigen, die keine Ahnung haben aber völlig schwachsinnig für diejenigen, die was davon verstehen. Manager eben.

Mich wundert eigentlich, dass Manager mehr verdienen, als die Entwickler, so die Manger selbst sagen, dass sie "nur" Manager sind.

Allesquatsch

Net Game schrieb:

Mich als blinder Maler bezeichnen zu lassen, wenn ich als "blosser" Manager Ideen, wie die Unixentwickler selbst habe, ist schon ziemlich derbe.

Immerhin scheint Manager-Kompetenz vorhanden zu sein: Du hast es gut auf den Punkt gebracht. :p

Aber mit Aussagen wie diesen

Net Game schrieb:

Ich überlege, ob es sinnvoll ist, wenn ich meine Programme in Zukunft als Client/Serverlösung programmiere, statt standalone, auch wenn dies nicht unbedingt nötig ist. Durch die Sockets, kann man mit dem Programm von außen während der Laufzeit kommunizieren und man hat viele Netzwerktools zur Verfügung.

würdest Du Dich als Mitglied jener Kategorie outen, zu denen auch Dilberts Chef gehört.

Ich habe in meinem Leben schon viele gute und genauso viele schlechte Besetzungen von leitenden Angestellten im IT-Bereich kennen gelernt. Darunter waren welche, die mal ihre Karriere als Programmierer begonnen hatten und viele, die erst ganz spät in den IT-Sektor gewechselt sind.

Selbst unter den echt Fachfremden (Juristen, Biologen usw.) waren viele fähige IT-Manager darunter, wenn sie denn wussten, wo ihre fachlichen Kompetenzen enden.

Am schlimmsten waren die, die (gerne aus Beratungshäusern kommend) ein punktuelles Halbwissen mit Selbstbewusstsein und Motivation so auffüllten, dass sie den eigenen Anspruch erfüllen konnten, sofort zu jedem Thema eine eigene Meinung präsentieren zu können.

Da war dann die persönliche Erfahrung, das heimische Netzwerk (1 DSL-Router und 2 Windows-Rechner) auf Windows XP zu bringen, schon ausreichendes Know-how, um zu wissen, wie man in einem Unternehmen mit 8.000 PC-Arbeitsplätzen eine Migration von NT auf XP durchführt.

Allerdings lasse ich die Möglichkeit offen, ob jemand, der tagsüber Beiträge in einem solchen Forum schreibt, wirklich zu der Kaste gehört, die ich als "Manager" bezeichne.

Seit einigen Jahren hat das, was ich so auf Visitenkarten lese, wo ich die Leute kenne, eher real-satirischen Wert: "CIO Production Site Castrop-Rauxel"

Ciao, Allesquatsch

hustbaer

Net Game schrieb:

Mich als blinder Maler bezeichnen zu lassen, wenn ich als "blosser" Manager Ideen, wie die Unixentwickler selbst habe, ist schon ziemlich derbe.

Ist "derbe" Manager-Speak für "total passend"?

Wobei, ne, nicht ganz passend. Ein blinder Maler müsste seine dummen Ideen selbst ausbaden.

Wenn du als Manager was verkackst kannst du dich dagegen leicht rausreden - die Programmierer sind schuld, weil die zu unfähig waren deine tolle Idee umzusetzen.