[Sugar-devel] [DESIGN] NetworkManager / Neighborhood design changes

[Peter Robinson]

Hi Sascha,

On Sun, Jun 5, 2011 at 3:14 PM, Sascha Silbe
<sascha-ml-reply-to-2011-3 at silbe.org> wrote:
> Porting Sugar to the NetworkManager 0.9 API and enabling new use cases
> (including connecting to networks with hidden SSIDs) requires some design
> changes in both the Neighborhood and the Frame. To get everyone on the same
> page, I will first give an overview of the NetworkManager API and list the
> (new) requirements. The suggested design changes and open questions will be
> discussed in detail during the upcoming Design Team meeting.
>
> NM 0.9 API
>
> Types of objects:
>
> Devices: Wired, Wireless, Modem, Bluetooth (DUN/PAN), OlpcMesh, WiMax
> Access Points (Wireless), NSPs (WiMax)
> Settings
> Active Connections
> VPN Connections
> VPN Plugins
>
> Activating a connection requires:
>
> a connection (setting?)
> a device (except for VPN)
> for wifi: access point (can be chosen automatically)
> for VPN: path of active connection ("base" connection)
>
> Global states:
>
> unknown
> no connectivity (asleep, disconnected, disconnecting)
> local, site, global connectivity
>
> Devices can be disconnected; no further automatic connection activation will
> happen for this specific device.
>
> VPN connections can be disconnected, regular connections can be deactivated.
>
> Wifi connections can be restricted to a single BSSID (expose in key dialog?)
>
> Networking can be globally en/disabled both totally and for classes of
> hardware (wifi, wwan=GSM/3G, wimax).
>
> Requirements
>
> Ability to activate a specific connection if multiple connections are
> available for a device / access point
> Ability to prevent automatic reconnections for a device (either via using
> the Disconnect() call for the device or disabling the entire hardware
> class); preferably happens by default
> Easy access to powering down a device class
> Ability to restrict a connection to a single AP (BSSID)
>
> Nice to have
>
> Ability to add a new connection for a device / AP that already has a
> configured connection
>
> Suggested design changes
>
> AP palette (Neighborhood):
>
> If there's more than one connection, list all of them. Selecting the
> connection activates it.
> If there's at least one connection, show option "Add another connection"
>
> Wireless device palette (Frame):
>
> New option "Connect to hidden network". Once the connection has been
> successfully configured, the AP should turn up as usual in the Neighborhood
> whenever it is in range (AFAIK at least).
> New option "Disable all wireless devices" resp. "Enable wireless devices"
> (wording could do with some improvement). If there is more than one wireless
> device, all of them will show the option and all of them will be powered
> down / up when the option is selected.
>
> "GSM" = Modem device palette (Frame):
>
> Behave like the new AP palette: list of connections, "Add another
> connection"
> New option to disable / enable WWAN devices, like for the wireless device
> palette
>
> Wired device palette (Frame):
>
> Analogous to GSM device, but no way to en/disable all wired devices (not
> supported by NM)
>
> Potential additions
>
> If we have enough time to implement these, we could add support for:
>
> Bluetooth (DUN/PAN)
>
> probably similar to modems ("GSM")
>
> WiMax
>
> probably similar to wireless
>
> VPN Connections
>
> would appear in the palette for any device that currently has an active
> connection
> no support for adding new VPN connections yet
>
> Open questions
>
> Should we continue to show the "Connect" option for APs if there's at most
> one connection configured or should we always show a list of connections?
> Rename "Add another connection" to "Add connection" if there's no connection
> configured yet?
> How do we distinguish the different connections in the list? User-chosen
> name? Add a way to change the name later?
> How do we let the user configure the connection? The current globally modal
> keyphrase dialog is a major usability disaster.
> Differentiated connectivity indicators (need to investigate work done by
> Peter Robinson and review previous design discussion)

I have a partially working patch for 0.9 support, I want to get it to
the point of Wired and AP connections working this week so I can get
SoaSv5 out the door with some sort of working wifi.

A couple of points from the quick read I had. WiMax is treated like
all other WWAN connections so should just work along with the GSM
stuff. The GSM stuff has been merged with all other WWAN techs (CDMA
etc) and is all one now so that should make it pretty easy to support
them all and any other types of "modem" connection.

It would be nice also to have a central "Flight safe mode" option that
deals with all Radios.

Peter