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

Will Stephenson lists at stevello.free-online.co.uk
Thu Nov 25 17:49:22 GMT 2004


On Thursday 25 November 2004 13:25, Harri Porten wrote:
> 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.

Here are some of the means of connection that could be used, characterised by 
connection mode and pricing model, that affect what the user will want the 
service to do, and illustrate the breadth of the different system level 
services we will need to control and listen to.

LAN		always on	flat rate
LAN is less dynamic, except when changing from eg Home static IP to Office 
dynamic IP + NFS environments...
PPP		temporary	flat rate 
PPP		temporary	time or bandwidth  based $$
As above, user may wish to use different connections based on environment eg 
flat rate ISDN while at home switching to dialup to office when on the road.
WLAN	always on	flat rate
WLAN 	always on	time or bandwidth based $$ (coffee shops, airports)

PPP includes analogue, ISDN, GPRS/GSM, Bluetooth

WLAN can be infrastructure or ad hoc.

Applications may only want connectivity or to be told when the connection is 
dead (see Kopete's Connection Status + SMPPPD plugin) but the user may want 
to set policies that require confirmation before bringing up expensive GPRS 
connections, for example.

Will
-- 
Will Stephenson
IRC: Bille




More information about the kde-core-devel mailing list