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