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