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
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
