Re: Proposal: NetworkManager for GNOME 2.18.



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]