Re: Proposal: NetworkManager for GNOME 2.18.

[Alp Toker <alp atoker com>]

Robert Love wrote:
> There is both a daemon and a client?  Explain.
>
> The daemon is desktop-agnostic.  It requires glib, HAL, and DBUS.  It
> runs as root, at the system-level, and enforces no policy, stores no
> settings, and maintains no state across sessions.
>
> The client, conversely, is policy-rich.  It provides a user interface,
> allowing user control.  There are currently two clients: nm-applet,
> GNOME's client, and KNetworkManager, KDE's client.  There is also plans
> for a command-line client.

There was another "client", the Banshee media player, which used to 
provide complete bindings for the NetworkManager API. Banshee was 
recently ported to use managed D-Bus[1], which does an automatic mapping 
of D-Bus API to the runtime, and NetworkManager support was ripped out 
of the code-base by abock out of frustration with the NM API.

The problem is that the NM API doesn't follow D-Bus conventions, which 
means that it has to be bound manually, or not at all. All other D-Bus 
APIs that Banshee uses like Gnome Power Manager, Notifications, HAL 
follow these conventions which means that they can be automatically 
supported with no effort. These APIs are fun to work with; 
NetworkManager is, on the other hand, a pain.

I'd like to convince abock to once again restore complete NetworkManager 
support in Banshee, but I don't think this will be feasible until 
NetworkManager gets an API review.

Perhaps the transition for inclusion in Gnome is a good time to start 
looking at the problems real programs are facing in integrating 
NetworkManager support?

The main issues are:

1) Inconsistent casing of API members:

  Signals are correctly cased:
    WirelessNetworkAppeared

  However methods break D-Bus naming convention:
    getActiveDevice

  This isn't Java, it's D-Bus, and while you're free to use whatever 
casing you want, in practice, breaking D-Bus convention will mean 
bindings are more difficult to use and maintain if you go that way.

2) Object paths are passed as strings instead of ObjectPaths:

  Name:  getActiveDevice  Return the currently active network device
  Args:  (none)
  Returns:  DBUS_TYPE_STRING  The NM identifier of a Device object

  This makes automatic mapping to a live object instance surprisingly 
difficult -- I can only imagine that you hard-code this case in your 
implementation. The fix to NetworkManager would be trivial as the wire 
representation of ObjectPaths and strings are identical other than the 
difference in signature, but doing this properly would save me and other 
binding authors a lot of time.

3) All signals seem to be on the Manager, rather than on the appropriate 
object:

  When a "DeviceStrengthChanged" signal is raised, I want it to be 
raised on the Device object, not the Manager. The way it's done right 
now just means clients and backends have to do more work bubbling 
signals to the correct object.

4) Interfaces have odd naming conventions:

  The interface name for a Device is
  "org.freedesktop.NetworkManager.Devices"

  This results in very strange looking code. What is a "Devices"?
  It should be a "Device", not a "Devices".

I'm certain that these inconsistencies are also a problem for the new 
automatic GObject/D-Bus binding work, but wouldn't be surprised if they 
affect the Python and Java bindings as well, depending on how much 
automation they provide.

There are a couple of other subtle issues but I don't want to go too far 
off-topic or appear to nit-pick about what's otherwise a great bit of 
software. My point is that this kind of API should be fixed before the 
NetworkManager public API is stabilised and sanctioned for use by Gnome 
applications, otherwise it will lead to a whole load of inconsistent 
code all over the place. Let's get this right from the start.

[1]: http://www.ndesk.org/DBusSharp