qtforum.de

Hi

ich möchte hier mal eine Idee vorstellen, Meinungen sammeln und wenn möglich Tools finden die es schon gibt die das tun.
Wenn nicht suche ich Leute die Interesse daran haben mir zu helfen es zu implementieren

Kurz es geht darum dass ich immer wieder Applikationen schreiben muss welche miteinander kommunizieren. Dabei geht es nicht um den Wunsch mal ein paar Daten auszutauschen sondern Funktionalität, also RPC.

Was mich etwas stört ist dass ich keine einfache Out Of the Box Lösung für QT finde welche sowohl einfach, wenig Overhead für den Entwickler, als auch Plattformunabhängig ist.
Wobei ich zugebe dass es bisher auch immer weniger zeitaufwendig war für die Projekte was zusammenzuhacken mit direkter TCP/IP Kommunikation als 2 Tage zu suchen.
Trotzdem stört das mein Entwickler Herz daher suche ich hier Hilfe.

Was ich grundsätzlich erreichen möchte ist, dass es für den Entwickler keinen Unterschied macht ob er Signals/Slots innerhalb des Prozesses verwendet oder ausserhalb.

Der Entwickler sollte also genau wie bisher sein
connect ( ptrSender, SIGNAL, ptrReceiver, SLOT ) machen können.
Der einzige unterschied ist dass ptrSender/ptrReceiver übers Netzwerk kommen.

Um den Mechanismus zu aktivieren müsste er einfach eine Klasse anlegen "NetworkSignal" oder so änlich, seine Objekte dort registrieren und Objekte mit Namen abfragen.
Im Idealfall erlaubt es die NetworkSignal Klasse auch mehrere Interfaces später zu bündeln, so dass man dann XML RPC, HTTP Rest, Corba, was auch immer austauschen kann. Aber eben transparent für den Entwickler.

Wenn ihr sagt "Super sowas gibt es" dann bitte WO !! und das bitte auch für Mac/Windows/Linux
Und wenn nicht ... hat jemand Lust mitzuschreiben ?

Grüsse
JarJar

Die Idee an sich iss gar ned verkehrt ...

Aber:

Bevor Du anfaengst zu implementieren solltest mal versuchen nen Lastenheft zu schreiben und versuchen genau zu spezifizieren, wie sich Deine Klassen zu verhalten haben, und zwar ned nur im idealfall, sondern in "ProblemSituationen". Glaub dann bekommst erstmal nen Gefühl, auf was Dich da einlaesst ^^

Punkte die auf alle faelle naehrer Erleuterung brauchen:

Verbindung:
- was soll passieren, wenn die Verbindung mittendrinn abreisst ? Muss der versender informiert werden und wie ? (globaler callback ?? )
- Sicherheitsfeatures ? sollen die verbindungen abesichert werden ?

Versionen / Binaerkompatiblitaet:
- sollen Programme unterschiedlicher QT Version miteinander koennen ?
- selbst bei gleicher Version ... wenn schon mal versucht hasst eine QT App gegen eine QT abhaengige Dll zu linken, die zwar gleiche QT version, aber inkompatible Buildflags verwendet, weisst was da lustiges passieren kann. Also den MetaKlass von QT fuer die assynchronen Connections wirst definitiv nicht verwenden koennen ^^
- sollen Windows-Apps mit Linux/Mac Apps ueber die Schiene Kommunizieren koennen ? Was passiert mit Objecten, die man so einfach nicht austauschen kann ???

Features:
- wie performant soll das ganze sein (protokoll frage)
- welche Objekte sollen als Parameter erlaubt sein ...
- sollen auch synchrone verbindungen möglich sein (aka der sender blockiert bis er ne bestaetigung bekommen hat). Timeoutproblematik ?


Also ich denk scho das mit einigen einschraenkungen sowas möglich waer. aber eben mit Aufwand.
Aber der Ansatz iss sehr sehr generisch. Eigentlich programmierst du damit viel zu weit um konkrete Anwendungsfaelle drumherum.

Ne aehnliche Technologie iss Corba und DCOM ...
Meine Erfahrungen sind, das sich die Softwaereschiene eher von diesen Schwergewichten wegentwickelt, sondern leichtgewichtigere Dinge für jeden einsatzfall angepasst werden. Einfach weils performanter wird.
Ich red nun nich von den Browser-Apps und Scriptsprachen, die ja tendentiell nach solchen Dingen gieren (Soap und co).


Ciao ...

Hi

Auf WAS ich mich da einlasse ist mir nicht ganz unbekannt. Meine Diplomarbeit war eigentlich genau so etwas, nur ohne QT und das ist inzwischen 10 Jahre her.
(Falls jemand die Firma Varetis, ehemals PC Plus, inzwischen goyellow kennt. Die hatten eine entsprechende Kommunikationsbibliothek für alle ihre Prozesse).

Verhalten bei Verbindungsabbrüchen, Datenaustausch, Peer2Peer connectivity usw. Da brauche ich im Endeffekt nur noch meine Diplomarbeit rausholen

Was mich hier aber interessiert ist speziell QT's signal Slot Mechanismus zu verwenden um es noch unsichtbarer zu machen. Denn zumindest damals gab es (da verschiedene Plattformen und Sprachen (Java, C, C++, Windows MFC, AIX, HP-UX, SOLARIS, LINUX) keinen bequemen Mechanismus die Messages in Functioncalls zurückzuverwandeln.

Corba war damals keine Alternative für uns, auch wenn ich inwzischen nicht mehr weiss wieso.

Mit dem Signal Slot und den QObject Metadaten sollte das aber mal grundsätzlich gelingen denke ich. Das einzige was etwas schwierig ist, sind komplexere Datentypen zu übertragen.
Wir haben das damals mit einer eigenen Container und Datenhaltungsklasse gelöst.

Aber ehrlich gesagt ... gibt es wirklich 10 Jahre später nichts was die Anforderungen erfüllt ?

Meine Erfahrungen sind, das sich die Softwaereschiene eher von diesen Schwergewichten wegentwickelt, sondern leichtgewichtigere Dinge für jeden einsatzfall angepasst werden. Einfach weils performanter wird.
Ich red nun nich von den Browser-Apps und Scriptsprachen, die ja tendentiell nach solchen Dingen gieren (Soap und co).

Es soll eben auch bewusst kein Schwergewicht werden. Eingeschränkte Funktionalität, reine Multithreaded Signal Slot Mechanik also (also automatisch asynchron) wäre vollkommen ausreichend.
Denn in 90% der Fälle will man einfach nur der einen Komponente in einem anderen Prozess mitteilen "Mach mal"
und das ohne jedesmal wieder das Rad neu zu implementieren und darauf läuft es im Moment leider immer hinaus.

Die Alternative komplexe Buildprozesse welche zusätzliche Precompiler und Generatoren einbeziehen um STUBS zu erzeugen, die Problematik zwischen lokal und remote explizit unterscheiden zu müssen ...

Also einfach eine Lightweight Solution, mit verschiedenen Protokollebenen erweiterbar um notfalls auch mal nen anderen Prozess als QT anzusprechen und im Endeffekt Signale, Slots mit Nativen und einem komplexen sich selbstbeschreibenden Datentyp auszutauschen.

Bewusst keine hochgeheim gesicherte Verbindung, keine high performance bzw. extreme reliability Lösung usw.
Denn die gibt es ... mit eben entsprechenden Aufwänden.

Viele Grüsse
Ciao