author | mickeyl <mickeyl> | 2002-11-03 13:35:57 (UTC) |
---|---|---|
committer | mickeyl <mickeyl> | 2002-11-03 13:35:57 (UTC) |
commit | 3bc2ff91e60f23dd235599b3d83471bde8be1c8a (patch) (unidiff) | |
tree | 9adf2c7c88228c78c2dc4c54f20986c56bfdb6c1 | |
parent | 02d98447805cd4b413d4841eadb9ca14271cd015 (diff) | |
download | opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.zip opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.gz opie-3bc2ff91e60f23dd235599b3d83471bde8be1c8a.tar.bz2 |
Added a proposal for the daemon/gui communication.
-rw-r--r-- | noncore/net/wellenreiter/docs/specification | 23 |
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 | |||
@@ -40,30 +40,51 @@ The configuration is done by both, the GUI and the daemon so that the | |||
40 | GUI only provides the graphical interface to the configuration library | 40 | GUI only provides the graphical interface to the configuration library |
41 | of the daemon. That means that the daemon loads the config file on | 41 | of the daemon. That means that the daemon loads the config file on |
42 | startup and sends the informations to the GUI. The GUI contains an option | 42 | startup and sends the informations to the GUI. The GUI contains an option |
43 | "configure" where the settings can be changed. They will be sent to the | 43 | "configure" where the settings can be changed. They will be sent to the |
44 | daemon which actually changes the configuration file. | 44 | daemon which actually changes the configuration file. |
45 | The configuration file is placed in /usr/local/etc/wellenreiter.conf. | 45 | The configuration file is placed in /usr/local/etc/wellenreiter.conf. |
46 | The whole content of this file cannot be specified yet. | 46 | The whole content of this file cannot be specified yet. |
47 | 47 | ||
48 | OPIE specific: Opie contains a bunch of high-level configuration classes, | ||
49 | which are used by most Opie applications. It should be discussed whether | ||
50 | to use this structure / API (preferred) or use a proprietary one. | ||
51 | |||
48 | 52 | ||
49 | -[ Interaction GUI<->daemon | 53 | -[ Interaction GUI<->daemon |
50 | 54 | ||
51 | The GUI and the daemon will talk actively with eachother, meaning that | 55 | The GUI and the daemon will talk actively with eachother, meaning that |
52 | everyside who has informations for the other part will send it and not | 56 | everyside who has informations for the other part will send it and not |
53 | wait for the other part to poll. | 57 | wait for the other part to poll. |
54 | For example the sniffing function of the daemon is startet when a | 58 | For example the sniffing function of the daemon is startet when a |
55 | "start_sniff" from the GUI arrived. And when the daemon found a network | 59 | "start_sniff" from the GUI arrived. And when the daemon found a network |
56 | it will be directly send to the GUI to be able to sniff in realtime. | 60 | it will be directly send to the GUI to be able to sniff in realtime. |
57 | 61 | ||
58 | 62 | ||
59 | -[ Communication GUI<->daemon | 63 | -[ Communication GUI<->daemon |
60 | 64 | ||
61 | Not yet specified. | 65 | The GUI and the daemon run as threads within one process, where the GUI |
66 | thread will be the main thread. Both the daemon and the GUI thread are | ||
67 | (mostly) "free-running". Once the GUI thread is started and has finished | ||
68 | its initializations, it jumps into the Qt event loop ( QApplication::exec() ). | ||
69 | |||
70 | If the daemon thread is actively working and - | ||
71 | for instance - has acquired interesting data for the GUI thread to display, | ||
72 | it calls a special reentrant method of the GUI thread ( QApplication::postEvent ) | ||
73 | either transmitting the whole data structure or saying "Hey, there's interesting data | ||
74 | for you", which the GUI thread then retrieves. | ||
75 | To enable a free running daemon thread to actually receive messages from the | ||
76 | GUI thread, it's useful to to include a non-blocking check-for-messages-function | ||
77 | within the daemon main loop <since it is waiting for messages from a GUI thread, | ||
78 | this function has not be called very often>. If applicable, the daemon thread must | ||
79 | not call this function but only monitor some guarded variables from time to time | ||
80 | which the GUI thread can modify to alter the behaviour of the daemon thread. | ||
81 | |||
82 | IMHO this is a much more leightweight design than to use a proprietary udp-socket protocol. | ||
62 | 83 | ||
63 | 84 | ||
64 | -[ Setting card modes | 85 | -[ Setting card modes |
65 | 86 | ||
66 | One of the most interesting parts is the switching of the wirelesscards to | 87 | One of the most interesting parts is the switching of the wirelesscards to |
67 | different channels, to monitor mode and so on. In the older versions this | 88 | different channels, to monitor mode and so on. In the older versions this |
68 | actions were done by the calling of external programs, that is now obsolete. | 89 | actions were done by the calling of external programs, that is now obsolete. |
69 | We will use the API of the wireless drivers to set it up. | 90 | We will use the API of the wireless drivers to set it up. |