Hallo ! Matt : You are some minutes faster than I :-) Have started writing about more-or-less the same you wrote just a few minutes ago. (should this also go to gnome-list ?) (Personal note: Due to hardware failure, I lost any mail (and lots of more data) send to me between Friday 15:00 MEST (last success mail-read) and Sunday morning (next try to download mail, interrupted by dying IDE-Controller at home.) ) On 28-Jun-99 Matt Koss wrote: > > Basically I wanted to make a signal / slot stuff for informing apps > about the connection and additionally to have a possibility to request > close connection. > > The proposed approach : > ------------------- > We can simply create a wrapper around NetMgr, let's say a class called > KNetMgr, which would use NetMgr methods to query a connection watcher, > and emit the appropriate signals. KDE apps would then have to create an > instance of this class and connect the signals to custom slots. It is the way I want to go. You may have read my answer to Waldo Bastians mail to both, gnome- and kde-devel-list, in which he suggested two setups (Message-ID: <3773538A.C5A55AC9@ens.ascom.ch>). I would prefer the first one. BTW: started writing a GUI for NetMgr. Anybody know a working gui-builder ? kbuild doesn't compile for me. > This general class is needed, because app should not have to keep the > information about the type of connection. I don't understand this line. what do you mean with "connection" here ? How to talk to NetMgr ? >>> "Bjoern.Kahl" wrote: >> >>>> What I wrote is supposed to be a generall, systemwide >>>> connecting-service. using X-Based thing will kill one of its >>>> design-goals: prevent timebased connecting and disconnecting >>>> from interrupting hand-made connectings: > > The proposed approach would conform to this, KDE apps would request / > close connection through NetMgr and if the connection is already here, > nothing would happen, as well as request for closing wouldn't close > connection if some app is still registered with NetMgr. > The above problem will be probably not present in home / one-user > systems, but the proposed approach would work in all environments. (-: The problem (unexpected closing by some application) *is* present in home / one-user systems (prof by example : my system :-)) ) > Kcm module would be used for configuring all features of NetMgr. User > could specify e.g. kppp or kisdn for connecting / closing. > I guess that this would require some more cooperation on kppp / kisdn > side in order to cleanly open / close connection ( kppp -k is not > enough ). This applies also to handling errors when connecting. Yes. Connecting & Errordetection: See (long) note at bottom of this mail. (Please, read that note, may answer some questions.) > Also requesting / closing of connections should be think out very > carefully maybe configuration on per-app basis ? This is really critical. Each Aplication using NetMgr should be required to let the user disable auto-connecting and to let the user explicitly confirm an connectionrequest. Perhaps as a radio-button-choice : "auto-connect" <-> "ask for connection" <-> "don't try to connect" It is surely nothing NetMgr has to deal with. How to use a service is the only responsebility of the application using that service. (Backgroundinfo: In germany, each successfull dial cost at least 12Pf, even if you are only 2 seconds connected. After that, (depending on day-of-week and time-of-day) each startet minute costs more or less an other 12Pf.) Some examples how applications can behave: Especially for short-time actions (like check for mail) it might be usefull, to wait until some other task initiates a connection. As soon as the connection is up, a mailclient may request also a connection (to hold the existing one) do its transfer, and drop the request. This could be repeated serveral times, as long as there is a connection (lets say: all 3 minutes). If there is no connection, the mailclient may try to connect in longer time periods (lets say: all 2 hour) (or, of course, when the user presses a "checkmail" button). Other application can then do the same trick, traveling on a its connections. > Another thing is starting of the NetMgr server. This would be probably > also configurable from kcm module - whether should it be started > automatically at the login or not (system could have it already > running, even before entering X) Next update (ready on my zip at home) comes with an SuSE-startscript to be inserted in /sbin/init.d/rc?.d . Expect this to appeare in CVS-kdenonbeta this evening. > BTW, is NetMgr suitable for ISDN connections ? > I am writing kisdn everywhere, but I still don't know if it can be used > here. Yes. (Please read:) Some Notes on how it works: NetMgr can do *every* dialup-connection that can be triggered via a shell-command (... AFAIK all currently available connection-types fullfill this requirement) (I use only ISDN at home.) Some lines above you talk abaut errorhandling: Connecting works this way: NetMgr fork()s a child, exec()s the configured shell-command for connecting, and wait until a special client (called "isonline") registeres and reports a successfully established connection. Currently "isonline" (and "isoffline" for disconnecting) sits in /etc/ppp/ip-up (resp. ip-down). /etc/ppp/ip-up gets called by (i)pppd when ever the link comes up, and ip-down is called when the link goes down. Disconnecting works the same way: NetMgr fork()s a child, exec()s the configured shell-command for disconnecting, and wait until a special client (called "isoffline") registeres and reports successfull disconnecting. Failure-detection: Both actions setup a timer. If timer expires, connecting (or disconnecting) is considered failed. Clients which have requested so, gets informed about failure (or success) via the NetMgr-notify-system. The whole think is asyncronous: "NetMgr_requestlink(NETMGR_CMD_ONLINE)" returns immediatly. An application has to wait for Notify-packet of type "online" or do (ugly) busywaiting via NetMgr_requestlink(NETMGR_CMD_CONNECTIONSTAT). Bjoern -- +-------------------------------------------------------------+ | Björn Kahl +++ | | Raum : II 204 +++ Tel. +49 431 880 3934 | | Institut für Experimentelle und Angewandte Physik, Uni Kiel | +-------------------------------------------------------------+