elanthis at awesomeplay.com
Wed Oct 1 22:08:07 EEST 2003
(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
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
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
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
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
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
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,
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.
More information about the xdg