network connections

[Sean Middleditch]

Hi list,

 (sorry if this gets duplicated, I sent once w/ the wrong address,
currently held up in admin que.)

 Most modern desktop systems are connected to a network (often the
Internet).  One problem facing network connections is that of
impersistent connections - the machine isn't always connected to the
network, or not always connected to the Internet.

 I've identified three scenarios:

1) Dialup and other on/off connections
2) Roaming users
3) Networks only occassionally connected to other networks

 Of these three scenarios, the user either

a) has the power to initiate a connetion
 or
b) does *not* have the power to initiate the connection

 I'm not going to cover (b) situations, since those aren't something to
be solved in a desktop - its an admin/policy issue, not a software
issue.

 The various utilities around today deal nicely with situation 2 -
roaming users that can control connectivity.  They basically detect the
current network, and configure accordingly.

 Situation 1 and 3 have been only partly solved to date.  In both
situations, the user is required to manually run some application in
order to bring up a connection, either from her machine to a network, or
her current network to another network.  The problem is, none of these
applications are integrated very cleanly with the desktop or desktop
applications.

 Imagine a user with dialup who wants to check her email.  In order to
do so now, she must:

 1) open the dialer
 2) initiate the connection
 3) open evolution/mailer

 On a certain other OS, and likely others, the user needs only open her
mailer.  The mailer will detect that the mail server(s) cannot be
reached, and open the dialer for her, perhaps even initiating the
connection automatically (if she wishes).

 What this needs on a Linux/UN*X box is rather simple: a standard
interface for requesting connectivity to a network.

 The interface should have the following capabilities:

 1) request a network by name
    reason/use: the user may have multiple connection profiles, some
    only for accessing certain private networks.  the connection manger
    can use the requested network information to default to an
    appropriate profile; i.e., not bring up the VPN connection to the
    office when Internet access is requested.
 2) notify app of connection status on request
    reason/use: when an application realizes it cannot connect to a
    network (i.e., you access yahoo in mozilla, and get a network
    unreachable error), the app will try to bring up the interface.  if
    the dialer interface doesn't then notify the app when the network
    is up, the app can't automatically retry the connection for the,
    unless it periodically polls.  and then, it wont know to stop
    polling if the connection cannot be made or the user declined the
    request.
 3) non-interactive connections
    reason/use: backgrounds tools may need access to a network at
    periodic times.  an automatic update utility, for example, or an
    outgoing mail processor.  (note: these are perhaps rare on a
    desktop system, but still valid configurations.)
 4) application blacklists/whitelists
    reason/use: the user should be able to specify that application X
    cannot request a connection (perhaps the app is buggy and requests
    a connection at inappropriate or annoying times).  this is
    especially important if the user enabled non-interactive
    connections.  likewise, the user may have interactive-only
    connections by default, but allow her mailer app to automatically
    open a connection, as she uses it so often.
 5) ability to use multiple backends
    reason/use: for a simple PPP connection, wvdial or another tool is
    easily usable.  but what about custom VPN solutions?  proprietary
    cell phone connection systems?  shared dialup connection managers?
    each connection profile needs to be able to specify how to start,
    stop, and query the connection's status, so that any kind of
    connection manager can be plugged in, but the user (and app
    developer) can be left with a single, clean API.  It may or may not
    be a good idea to also standardize the configuration interface for
    a backend - it could be possible to use an XML settings definition
    and have user input fed to a fourth script/tool for settings, but
    that may be too limiting.
    
The system above needs three parts:
 1) a standard interface for scripts/apps to request and query the
connections.
 2) a user interface for selecting profiles on interactive connections,
or configuring available connections.
 3) a standard configuration format/area for multiple user interfaces to
easily share connection profiles.

I'm thinking, D-BUS can be used for the app connect interface.  A small
wrapper library can be provided of course to ease the use of the
interface.

Multiple interfaces would allow a custom GNOME dialer, perhaps a
modified KPPP for KDE, and other good-fit dialers for other desktops. 
plus, nothing really says the user will be in a desktop; perhaps a
startup script for the OS detects that important hardware (like a video
card) has no usable driver, and wants to initiate a conncetion to
download an appropriate one.  thus, a console UI would be quite useful,
and possible.

What does everything think of this?  I've tried to find every all the
important points, which I hope I've accomplished.  If the above looks
alright, then it should be possible to start hammering out a more
technical proposal, including the D-BUS message interface, connection
backend protocol, and get a sample implementation up and running.
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.