Re: using nm-system-settings for the user settings

[Dan Williams <dcbw redhat com>]

On Thu, 2009-05-14 at 14:54 +0200, Martin Vidner wrote:
> Hi,
> 
> in NM clients, such as the GUI applets and the CLI of yours truly, a
> fair amount of code deals with the connection settings. I got the
> idea that the current nm-system-settings service could be
> generalized to deal with the *user* settings too, so that one
> program could run as two processes serving the two services. That
> way the client code would be factored out in the separate settings
> service. One could then even use the same connections from different
> applets, unlike now when they are stored in KDE and GNOME specific
> stores.

You can already use the same connections from different applets if you
want to, anything can ask the user session applet for the list of
connections, and then it can tell NM to activate that connection.  I can
use dbus-send to activate a user connection if I want to, as long as
that dbus-send call is done as the same user the applet runs as.

> I started coding it, registering nm-system-settings at
> NetworkManagerUserSettings, wanting to continue with the config file
> location and PolicyKit restrictions.
> 
> Dan, Tambet told me that you intend to merge nm-system-settings into
> NM itself. I am afraid that it goes in pretty much the opposite
> direction than I would need. Could you share some details and
> reasons for the merge so that we can try to make the ideas work out
> together?

Reasons for the merge are:

(a) elimination of a running process
(b) reduce latency of unmanaged device discovery
(c) code reduction in NM because IPC between NM and the system settings
service would no longer be required
(d) ability to store more things like persistent Wireless Enabled,
Network Enabled, and device states in system config files

Basically, I didn't see a compelling case for it to still be separate
from NetworkManager.  Obviously the
org.freedesktop.NetworkManagerSystemSettings service would continue to
be provided.  I still don't see a very compelling reason to factor the
user settings code out of the applet; it was stuck back into the applet
(remember NetworkManagerInfo anyone?) a long time ago because having it
separate was architecturally messy and had no benefit at the time.

Dan