summaryrefslogtreecommitdiff
authormickeyl <mickeyl>2002-11-03 13:35:57 (UTC)
committer mickeyl <mickeyl>2002-11-03 13:35:57 (UTC)
commit3bc2ff91e60f23dd235599b3d83471bde8be1c8a (patch) (side-by-side diff)
tree9adf2c7c88228c78c2dc4c54f20986c56bfdb6c1
parent02d98447805cd4b413d4841eadb9ca14271cd015 (diff)
downloadopie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.zip
opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.gz
opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.bz2
Added a proposal for the daemon/gui communication.
Diffstat (more/less context) (ignore whitespace changes)
-rw-r--r--noncore/net/wellenreiter/docs/specification23
1 files changed, 22 insertions, 1 deletions
diff --git a/noncore/net/wellenreiter/docs/specification b/noncore/net/wellenreiter/docs/specification
index d833451..0766ef4 100644
--- a/noncore/net/wellenreiter/docs/specification
+++ b/noncore/net/wellenreiter/docs/specification
@@ -42,12 +42,16 @@ of the daemon. That means that the daemon loads the config file on
startup and sends the informations to the GUI. The GUI contains an option
"configure" where the settings can be changed. They will be sent to the
daemon which actually changes the configuration file.
The configuration file is placed in /usr/local/etc/wellenreiter.conf.
The whole content of this file cannot be specified yet.
+OPIE specific: Opie contains a bunch of high-level configuration classes,
+which are used by most Opie applications. It should be discussed whether
+to use this structure / API (preferred) or use a proprietary one.
+
-[ Interaction GUI<->daemon
The GUI and the daemon will talk actively with eachother, meaning that
everyside who has informations for the other part will send it and not
wait for the other part to poll.
@@ -55,13 +59,30 @@ For example the sniffing function of the daemon is startet when a
"start_sniff" from the GUI arrived. And when the daemon found a network
it will be directly send to the GUI to be able to sniff in realtime.
-[ Communication GUI<->daemon
-Not yet specified.
+The GUI and the daemon run as threads within one process, where the GUI
+thread will be the main thread. Both the daemon and the GUI thread are
+(mostly) "free-running". Once the GUI thread is started and has finished
+its initializations, it jumps into the Qt event loop ( QApplication::exec() ).
+
+If the daemon thread is actively working and -
+for instance - has acquired interesting data for the GUI thread to display,
+it calls a special reentrant method of the GUI thread ( QApplication::postEvent )
+either transmitting the whole data structure or saying "Hey, there's interesting data
+for you", which the GUI thread then retrieves.
+To enable a free running daemon thread to actually receive messages from the
+GUI thread, it's useful to to include a non-blocking check-for-messages-function
+within the daemon main loop <since it is waiting for messages from a GUI thread,
+this function has not be called very often>. If applicable, the daemon thread must
+not call this function but only monitor some guarded variables from time to time
+which the GUI thread can modify to alter the behaviour of the daemon thread.
+
+IMHO this is a much more leightweight design than to use a proprietary udp-socket protocol.
-[ Setting card modes
One of the most interesting parts is the switching of the wirelesscards to
different channels, to monitor mode and so on. In the older versions this