Re: Proposal: NetworkManager for GNOME 2.18.
- From: "John (J5) Palmieri" <johnp redhat com>
- To: Alp Toker <alp atoker com>
- Cc: desktop-devel-list gnome org
- Subject: Re: Proposal: NetworkManager for GNOME 2.18.
- Date: Thu, 19 Oct 2006 16:47:21 -0400
On Mon, 2006-10-09 at 05:57 +0100, Alp Toker wrote:
> 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?
I completely agree here.
> 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.
This part I would let slide. The caps issue is simply a convention and
not something anyone should rely on. It might be an annoyance to some
but such is life.
> 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.
Yes, a throwback from the old days when we didn't have object path
types. This should be changed.
> 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.
Agreed here too. Also having the signals on the devices allows you to
ignore devices you care nothing about.
> 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".
Again not a big deal but if we are going to change a bunch of things
this might as well be changed for clarity.
> 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.
We should deprecate the old API and get a new clean API working before
we approve this module for inclusion (so I take back my original thumbs
up and put it at -45 degrees from up). Dan Williams is well aware of
the API suckyness. It was one of the first D-Bus interfaces and the
first one he had done. He had plans for revamping it and I am sure he
would appreciate input and help from others.
--
John (J5) Palmieri <johnp redhat com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]