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

[Waldo Bastian]

> > Proposed DCOP interface
> > =======================
> >
> > enumOnlineStatus { Unknown = 0, OffLine = 1, Online = 2 }
>
> Wouldn't we need additional intermediate states here, something like
> RequestedOffline and RequestedOnline? 

Would that add value? Are their cases where you would want to treat these 
differently from the "Offline" state? Then again, probably the same can be 
asked about "Unknown" and "Online".

> It might take a while to get online
> and when going from Online to Offline it would be desirable to wait with
> actually switching off the network until pending network operations are
> finished.

In order to support gracefully going offline we would need to keep track of 
all pending network operations (something slavebase already provides for btw)
For the kded module I think it would be enough if applications could inform it 
about "no network operation active" and "network operation may be active" and 
in the latter case establish some "please shutdown" call together with a "ok, 
done" / "please cancel shutdown" reply. A bit like the queryClose stuff that 
session management does. If you are going to query the user then there is the 
"Never mind, the network disconnected itself already" case to keep in mind as 
well :-)

If you want to take "local access" into account as well, it becomes a bit more 
tricky because then you also have to solve the problem of figuring out which 
connection is affected and which is not.

> > 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?) )
> > // Sets internet status, to be used by kppp / kisdn or distribution
> > specific // tools
>
> Is this meant to set the status reflecting the actual network state or to
> request a status change?

It is meant to set the status reflecting the actual network state.

> Or asked in a different way: Would kppp call this function or be called by
> this function?

kppp would call this.

> > 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
>
> How would this callback be used?
>
> Might it be desirable to not require DCOP here, so that distribution
> specific tools don't need to be able to use DCOP?

In KDE4 they will be able to use DBUS instead. I don't think it makes sense to 
develop a new IPC mechanism just to fill the gap till then. Note that they 
can use the dcop command line utility as long as we don't put non-standard 
data types in the DCOP interface. That's a point to keep in mind of course.

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/41196c91/attachment.sig>