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

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...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]