RFC: Keeping track of online/offline status & central DNS service

Harri Porten porten at froglogic.com
Thu Nov 25 13:25:46 GMT 2004


On Thu, 25 Nov 2004, Waldo Bastian wrote:

> > What if there are multiple ways to connect to the Internet? Somehow the
> > notion of a "profile" would be nice where a different connection would be
> > used depending whether you are at home (LAN, DSL etc.) or travelling (cell
> > phone etc).
>
> Good point. I guess from an application point of view you will still
> have only one overall status, but e.g. kppp may think you are offline
> while at the same time your wireless is online, the kded module should
> be able to process that conflicting information and conclude that you
> are in fact online.

Actually, I was originally thinking of the case where the connection
facility itself has different modes (kppp allows easy selection between
different modems because of that now). But one probably does not have to
worry about how many different tools are involved. The user can just set
up both "FooDialer (Mobile)" and "FooDialer (ISDN)" and would
be free to chose one and the same dialer for both profiles as long as
there is some way to pass a different switch.

> > So it might be useful to have both pre and post signals for triggering
> > certain actions. Whether that should be crammed into the enum or in
> > additional signals I don't know.
>
> Do you have examples where these are used?

I just know it had been requested several times ;( Maybe to sync edit
data? But that would require the possibility to defer the disconnection.

> What is the semantics of "aboutToDisconnect"? Will the application have
> time to do anything before the connection disappears? What if the
> connection disappears unexpected?

That's indeed a weakness. There may be cases where it's not emitted. Also
see the comments in kppp/KPPPIface.h.

[...]
> And I guess this function requires the notion of a "profile" then, just like
> setOnlineStatus().

Yeah.

I'll have to think more of the rest of problems you brought up.

Harri.





More information about the kde-core-devel mailing list