[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RE: Little Summary of "Daemon for managing dialup internetconnec
From:       Matt Koss <koss () napri ! sk>
Date:       1999-06-29 11:01:30
[Download RAW message or body]

On Po, 28 jún 1999, you wrote:
>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.

At least we finally both got to the same point :-)

>
>> 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 ?

What I mean is, that networking app should not care at all about the type of the
connection to Internet.
The app would just use KNetMgr class, watch "connected" signal and possibly
issue connect / disconnect request.
This means, that app would use the same behaviour even if there is a permanent
connection to Internet.
KNetMgr class would take care of this, and according to the type of connection
would either connect to NetMgr server or not.  E.g. for permanent connection
KNetMgr would simply only emit signal "connected( true )". Analogically, when
requesting connection, the class would do nothing.

This way the application wouldn't have to read a config file to get the type of
connection, neither have some option in the preferences dialog.
Everything would be then configurable through one general kcm module.

>
> 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.

Exactly.
Some apps could be set to wait until the connection is up.
Others could be allowed to request connection.

>
> Next update (ready on my zip at home) comes with an
> SuSE-startscript to be inserted in /sbin/init.d/rc?.d .

Fine.

>
>> 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.

Great.

>
>  Some lines above you talk about 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.

That's nice, but how will it interfere with kppp / kisdn ?
AFAIK kppp has it's own timer for failure detection. I don't know 'bout kisdn.

BTW, as Waldo suggested, we could still make KNetMgr also a wrapper for CORBA
stuff. As Miguel wrote, GNOME people might follow on this,  so there is no need
to throw away this chance.


     regards

			Matt

-- 
Matej Koss	e-mail: koss@napri.sk
Kosice		 ICQ# : 19344305
Slovakia

[prev in list] [next in list] [prev in thread] [next in thread]