Re: Feature request: Add a method to NetworkManagerSettings interface to create a new auto connection for a specified device.

[Dan Williams <dcbw redhat com>]

On Thu, 2008-10-30 at 15:43 +0800, Zhe Su wrote:
> Oh, thanks. I didn't notice that there is a AddConnection() method in
> SystemSettings service. Seems that it's not in current public api
> documentation. And I'm wondering why user settings service doesn't
> have similar method.

It's defined in the introspection/ directory, most of which is public
API.  If you build with --with-docs=yes, you'll get it in the
NetworkManager spec in docs/.

dan

> I'll try this method and give you feedback.
> 
> Regards
> James Su
> 
> On Thu, Oct 30, 2008 at 2:42 PM, Dan Williams <dcbw redhat com> wrote:
>         
>         On Thu, 2008-10-30 at 13:45 +0800, Zhe Su wrote:
>         >
>         >
>         > On Thu, Oct 30, 2008 at 12:53 PM, Dan Williams
>         <dcbw redhat com>
>         > wrote:
>         >         On Wed, 2008-10-29 at 22:30 +0800, Zhe Su wrote:
>         >         > Hi,
>         >         >   Currently, NetworkManagerSettings interface has
>         method
>         >         > ListConnections() to list all existing
>         connections.
>         >         > NetworkManagerSettings.Connection interface has
>         method
>         >         Update() to
>         >         > update properties of a connection, and Delete() to
>         delete
>         >         the
>         >         > connection. But there is no method to create a new
>         auto
>         >         connection for
>         >         > a specified device. Thus, it's impossible to fully
>         control
>         >         network
>         >         > manager and its applet from another application
>         without
>         >         implementing
>         >         > its own settings service.
>         >         >   My suggestion is to add a new method to
>         >         NetworkManagerSettings
>         >         > interface, say NewAutoConnection (or similar), to
>         create a
>         >         new auto
>         >         > connection for a specified device. Input parameter
>         would be
>         >         the device
>         >         > path and returns the path to newly created
>         connection.
>         >
>         >
>         >         You'd need to take into account different device
>         types,
>         >         because for some
>         >         devices (wifi) you also need to specify some AP
>         >         characteristics (at
>         >         minimum, the SSID).  Just NewAutoConnection() would
>         be too
>         >         simple.
>         > After creating the new connection, application can fill in
>         the
>         > required properties by calling connection's Update() method.
>         
>         
>         No, because the connection would be invalid until you fill the
>         properties in.  You need to set the properties when the
>         connection is
>         created (and thus it's valid) otherwise it won't be exported
>         by the
>         settings service, and then you wouldn't be able to call
>         Update().
>         
>         >
>         >
>         >
>         >         It also shouldn't take a device path, because
>         connections
>         >         aren't tied to
>         >         a particular device at all; they can apply to any
>         device of
>         >         the same
>         >         class.  The way you tie a particular device to a
>         connection is
>         >         by
>         >         locking the connection to the MAC address of that
>         device.
>         >          That's a
>         >         property of the connection, and something that the
>         caller of
>         >         NewConnection would pass in the connection settings.
>         > Then NewConnection() method can just create a new empty
>         connection
>         > without any property. Without this method, there is no way
>         to an
>         > application to create a new connection at all.
>         
>         
>         See above.
>         
>         >
>         >
>         >         >   With this new method, the API would be
>         self-contained. 3rd
>         >         > applications would gain full connection
>         manipulation ability
>         >         solely
>         >         > via dbus, without linking to libnm-glib and
>         libnm-utils.
>         >
>         >
>         >         To be fair, libnm-glib and libnm-util have never
>         been
>         >         requirements, they
>         >         are simply convenience libraries.  Its quite
>         possible to do
>         >         everything
>         >         the applet does in Python using plain D-Bus.
>         > Yes, it's possible, but if there is no external settings
>         service that
>         > supports creating new connection via dbus, application must
>         setup its
>         > own settings service and provide connection information by
>         itself.
>         > It's far more complex and it's currently impossible in our
>         > application.
>         
>         
>         Ah, but there is: the system settings service :)
>         
>         >         Basically, you can do all of this today using the
>         system
>         >         settings
>         >         service if you like, with the keyfile plugin,
>         authenticated by
>         >         PolicyKit.  This is how the connection editor
>         already works
>         >         when
>         >         creating new system connections, or when moving a
>         connection
>         >         from user
>         >         to system scope.  I'd suggest using the system
>         settings
>         >         service instead
>         >         of the applet, since that also allows the connection
>         to be
>         >         used before
>         >         login and across fast user switches.
>         > How to create a new connection in system settings service
>         via dbus?
>         > It's not feasible for us to depend on anything else except
>         dbus.
>         
>         
>         You put together the properties you want the connection to
>         have, then
>         you call
>         org.freedesktop.NetworkManagerSettings.System.AddConnection()
>         method of the system settings service, and pass in the dict of
>         dicts
>         that specifies the connection you wish to add.  The outer dict
>         is the
>         "Connection" object, which contains a string::dict mapping of
>         "Setting"
>         objects.  Each Setting object is itself a dict of
>         string::<type>
>         mappings that specify the properties of that setting.  There
>         are
>         settings for wireless, IPv4, wireless security, wired, 802.1x,
>         vpn,
>         pppoe, etc.
>         
>         The settings service has absolutely no idea what sort of
>         connection you
>         want to create; for wireless you need to specify the SSID at
>         least, and
>         you probably want to specify the security options too.  For
>         VPNs, you'll
>         need at least the VPN gateway IP address and the username or
>         certificates too.  For wired you can usually get away with
>         just DHCP.
>         For mobile broadband, you'll need the dialing # at a minimum,
>         and
>         probably the APN as well.  Without a certain set of parameters
>         that
>         depend on the specific connection type, the connection is
>         simply invalid
>         because it cannot be activated.  And only you as the user or
>         programmer
>         know what those parameters actually are...
>         
>         Dan
>         
>         
>         
>