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

[Waldo Bastian]

On Thursday 25 November 2004 12:24, Harri Porten wrote:
> Hello Waldo,
>
> On Thu, 25 Nov 2004, Waldo Bastian wrote:
> > Proposed DCOP interface
> > =======================
> >
> > enumOnlineStatus { Unknown = 0, OffLine = 1, Online = 2 }
> >
> > enumOnlineStatus (int?) onlineStatus()
> > // Returns internet status, can be used by applications such as KMail /
> > // KWeather in deciding whether to do certain background activities
> >
> > void setOnlineStatus(enumOnlineStatus (int?) )
>
> 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.

> > // Sets internet status, to be used by kppp / kisdn or distribution
> > specific // tools
> >
> > signal onlineStatusChanged(enumOnlineStatus (int?) )
> > // DCOP signal that gets emited whenever the onlineStatus changes
>
> If you look at the signals of KpppIface you'll notice 4 different once:
>
>  void aboutToConnect();
>  void connected();
>  void aboutToDisconnect();
>  void disconnected();
>
> 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? What is the semantics of 
"aboutToDisconnect"? Will the application have time to do anything before the 
connection disappears? What if the connection disappears unexpected?

> > setNetworkActivationCallback(DCOPRef, function)
> > // Specify DCOP function that should be called in order to request
> > activation // of network
> > // To be used by kppp / kisdn or distribution specific tools
>
> Or is this the one you meant to (partially) achieve the purpose depicted
> above?

It lets kppp say to kded "if you want network, call me", and when the kded 
module decides that the network should be activated it will call kppp, and at 
that point you would expect to see "aboutToConnect()" from kppp. I think such 
call to kppp should also give a return value that indicates something like 
"ok, I'm about to connect, stay tuned" and "i'm not going to connect".
Then, when the connection actually happens kppp will call setOnlineStatus 
(together with "connected()" from kpp), what is missing then is a way for 
kppp to say "I tried but failed".

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

Such profile should have a user visible name associated with it, so that we 
can let the user select "connect via a) XXX or b) YYY". A profile could then 
mean a specific interface (e.g. analog or isdn) but could also differentiate 
between different service providers on the same interface.

I wonder if wireless access has specific requirements in this area, are their 
use-cases where different wireless access profiles become dynamically 
available and where you want to wait on user action before actually providing 
the user with the available possibilities to set up access?

Shuld the concept of "local access" be coupled [optionally] to a profile as 
well? (use case: laptop in local network with local access to workstation or 
mailserver, home network may or may not provide internet access, when 
disconnected from local network laptop can use dial-in for internet access, 
but will have no "local access" to mailserver)

Should profiles be exposed to applications? The above use-case suggests that 
KMail may need to use different ways to access mail depending on the network 
connectivity. Is it enough if the DNS lookup function mentioned in my 
previous mail is aware of the availability of "internet" and "local 
network" (in which case it can immediately return a "network unavailable" 
error to kmail when kmail tries to access an unavailable mailserver), or 
would KMail want to expose connection profiles in its GUI by, for example, 
coupling its various accounts with connection profiles?

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041125/0a12b07a/attachment.sig>