Scope

This covers only the conceptual model that NM would use internally, and in the communication with the info-daemon, for configuration of network devices.

Conceptual Objects

Device: A hardware device that is the immediate provider of network connectivity. Wireless card, bluetooth dongle, serial modem, PCI ethernet card, USB wireless or ethernet card, etc. Devices are classified into different "types", ie 802.11 wireless, ethernet, modem, etc.

Connection: a specific, encapsulated, independent group of settings describing a complete network configuration. Referred to by a unique identifier. A connection is tied to a one specific Device type (but not a specific device like eth1). It is composed of one or more Settings objects.

Setting: a group of related key/value pairs describing a specific piece of a Connection. Settings keys and allowed values are described in detail at NetworkManagerConfigurationSpecification.

Conceptual Diagram

  - 0 (Connection)
    |
    |- connection (Setting)
    |   |- name: 'nifty-wireless'
    |   |- devtype: '802-11-wireless'
    |   `- autoconnect: True
    |
    |- 802-11-wireless (Setting)
    |   |- ssid: 'nifty-wireless'
    |   |- mode: 'infrastructure'
    |   `- seen-bssids: ['xx:xx:xx:xx:xx:xx', 'yy:yy:yy:yy:yy:yy']
    |
    |- 802-11-security-wpa (Setting)
    |   |- proto: 'WPA'
    |   |- key_mgmt: 'WPA-PSK'
    |   |- pariwise: ['TKIP', 'CCMP']
    |   |- group: ['TKIP', 'CCMP']
    |   `- psk: '9ad8da8a8da8f8dsa8...'
    |
    `- ip4 (Setting)
        |- dns: ['1.1.1.1', '1.1.1.2']
        `- dns-search: 'foobar.com'

- 1 (Connection)
    |
    |- connection (Setting)
    |   |- name: 'Work @ BigCorp'
    |   `- devtype: '802-3-ethernet'
    |
    |- 802-3-ethernet (Setting)
    |   `- MTU: 1500
    |
    `- ip4 (Setting)
        |- address: 10.1.1.50
        |- netmask: 255.255.255.0
        |- gateway: 10.1.1.1
        |- dns: ['10.1.1.3', '10.1.1.4']
        |- dns-search: 'bigcorp.com'
        `- ypbind: ['1.1.1.3']

- 2 (Connection)
    |
    |- connection (Setting)
    |   |- name: 'Sprint PCS'
    |   `- devtype: 'bluetooth'
    |
    |- bluetooth (Setting)
    |   |- rfcomm-channel: 4
    |   `- device: xx:xx:xx:xx:xx:xx
    |
    `- ppp (Setting)
        |- number: '#777'
        `- compression: True

• Each Settings object has strictly defined key names and strictly defined value types for each key. When keys are not present, they assume a default value. For example, if static IP settings are unspecified in the 'ip4' Settings object, it is assumed that DHCP is used. (FIXME:

• It's up to the info-manager to store this information in a form of its choice and reproduce it on demand. Either GConf, LDAP, KConfig, whatever.

• NetworkManager will request the connection objects from the info-daemon, and perform validation on them. If a Settings object's key or values are invalid, the Settings object is rejected and not used or exposed by NetworkManager. NM should log the error or provide some easy way to tell what's wrong with a Settings object so it doesn't just disappear for no observable reason though.

• The Connection's identifier should not be derived from the connection's name in any way and can be randomly assigned, but must be persistent for the lifetime of the NetworkManager process, and connection identifiers must not ever be re-used for a different Connection object.

• Settings are applied in a predefined order. Obviously we have to bring up a wireless connection and auth to the AP before we can apply IP settings. This logic will be built into NM.
• Connections will be transported across D-Bus as an array of dicts. Each dict corresponds to a Settings object. At least the 'connection' settings object and it's associated type object are required. (FIXME: is this the best encapsulation mechanism or are named Connection objects the best way to go?)

System-wide Configuration

• NM cannot rely upon a user info-daemon for system-wide settings (privileged settings/admin settings maybe?). This means that we probably have to have 2 info-daemon services running at the same time; one for system-wide settings that runs from boot to shutdown, and a user-level info-daemon service that provides user-specific settings only during the user's session.
• We're not about to create an NM-specific shadow configuration system. We need to reuse the current options for user-specific preferences, either GConf or KConfig or whatever.
• Assuming we do run two info-daemon services; they will both use the exact same interface with NM, and may even be the exact same executable. We could use nm-applet and simply pass it a command-line option like '--no-gui' or something.
• NM would be responsible for merging the configuration from both services, and for ensuring that administrator/system-wide configuration overrides user configuration.
• The system-wide info-daemon can pull the configuration from anywhere it wants, either from mandatory/default GConf settings, /etc/sysconfig files, or whatever, as long it can coerce the data into the Connection+Setting model specified here.

Future

• Make it easy for new Settings objects, like VLANs or bridging or Internet Connection Sharing, to be integrated into the model. Then all that needs to be done is write the Settings object spec, the verification code in NM, and the operational code to use the Settings object.
• Using dicts for the transport format makes it easy to maintain backwards compatibility, since the function prototypes aren't as fragile

• Ethernet over USB with DHCP configuration.