Client/Server vs standalone
-
Gibt es eigentlich noch andere Lösungen, um auf den Datenstrom eines Programmes zu zugreifen?
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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
-
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.
