Announcing ConnMan.net [LWN.net]

Announcing ConnMan.net

Posted Jun 24, 2009 8:55 UTC (Wed) by danpb (subscriber, #4831)
In reply to: Announcing ConnMan.net by njs
Parent article: Announcing ConnMan.net

The points the ConnMan PDF raises against NetworkManager were all valid criticisms of the 0.6.x release series of NM, but none of them were fundamentally unfixable flaws. Indeed this is highlighted by the fact that a great many of the 'problems' were addressed in the 0.7.0 series of NM. So I can't help thinking the decision to start writing from scratch was not the most effective use of resources.

to post comments

Announcing ConnMan.net

Posted Jun 24, 2009 14:44 UTC (Wed) by wstephenson (guest, #14795) [Link] (6 responses)

Try implementing a NetworkManager 0.7 client then. There is still a lot of boring work every client has to do to make the objects NM exposes on the bus into something that the user can interact with.

Announcing ConnMan.net

Posted Jun 24, 2009 16:11 UTC (Wed) by nirik (subscriber, #71) [Link] (4 responses)

cnetworkmanager?

http://vidner.net/martin/software/cnetworkmanager/

Announcing ConnMan.net

Posted Jun 24, 2009 16:20 UTC (Wed) by wstephenson (guest, #14795) [Link] (3 responses)

Martin's client is great for what it does, for example if you just want to connect to a WPA-PSK network from the command line, but it's very limited.
I meant a full-featured client that starts with the desktop session, saves configuration to disk (and securely where appropriate) and has a UI.

Announcing ConnMan.net

Posted Jun 24, 2009 16:28 UTC (Wed) by dcbw (guest, #50562) [Link] (2 responses)

Of course this takes some code, just like for example writing a usable display configuration applet that handles monitor hotplug and removal, configuration-on-the-fly, saved settings, etc. When you're dealing with hardware and configuration, you need to write the code to deal with that hardware and all the configuration options.

But since you've implemented the plasma stuff, I'm curious what your suggestions would be for making it easer. How can the D-Bus interface be improved? What can be made simpler, ensuring that the flexibility of the configuration system is retained?

It would be a lot simpler if we could get rid of ActiveConnection and just use the Device object, but unfortunately, we're just about to add bridging support, and that's going to make the ActiveConnection class have more than one device in the "Devices" property.

Networking is a complex problem, and if you want to solve users' needs, you often need to write non-trivial amounts of code to make sure it's possible and easy for the user. Often that means it's harder for the develoepr.

Announcing ConnMan.net

Posted Jun 24, 2009 16:47 UTC (Wed) by wstephenson (guest, #14795) [Link] (1 responses)

The simplifying approach I've taken for KDE, to make it possible for non-NM specialists to work on the GUI, is to produce a high level flat list of "things that the user might want to click"

1) Wireless networks (as the NM dbus api only gives a list of access points)
2) Connection on an Interface.

This list is pre-filtered on appropriateness (a fuzzy definition but you know what I mean - don't list any connections where a matching AP is not visible - don't list wired connections when there is no cable inserted, don't show anything wireless when in flight mode, etc).

From what I've read of the ConnMan docs so far, they have taken a similar approach in what is presented to the client, giving up some correctness and flexibility in the model (at that layer) for ease of use.

Announcing ConnMan.net

Posted Jun 24, 2009 18:27 UTC (Wed) by dcbw (guest, #50562) [Link]

You'll probably remember that NM 0.6 did group "networks" together for you. That turned out to be a huge mistake in the daemon, because you need to separate networks based on SSID, capabilities, and band. Unfortunately, trying to over-simplify things is exactly what caused problems with NetworkManager 0.6, since you simply cannot trust people to actually name their access points reliably. Thus you end up with situations where you have two APs called 'linksys' with different security settings, and the user wants to connect to the higher-security one, but not the lower-security one. Or, their linksys AP is on the A-band, but their neighbors is on the B/G band.

Similarly, we found that *not* showing interfaces that were disabled or not managed by NM caused *huge* numbers of bug reports, mostly from Ubuntu users asking "where's my wifi card" when Ubuntu set their wifi card unmanaged by default and it disappeared from the applet.

So the gnome applet tries to give you an informed view of your machine, including why you can't do some things you may want to, instead of just hiding those items completely. The same reason why menu items get disabled rather than hidden outright.

Announcing ConnMan.net

Posted Jun 24, 2009 16:24 UTC (Wed) by dcbw (guest, #50562) [Link]

That's only if you want to implement user-specific connections like the applet does, which are completely optional. If you simply want to use system connections, which are handled entirely by NetworkManager, then you don't need to be a service on the bus at all. That's 66% of what nm-applet is doing; if you strip that out, it's really just some dbus calls and a GtkMenu. I should really write a minimal client just to dispel this sort of FUD.

I'm curious about the "boring work" you refer to. Using a library that makes it easy for you like libnm-glib, or by using python, it's pretty darn easy. But for a UI to be usable, you still need to ensure that you don't show the user things which aren't applicable to their situation, do proper error checking and notification, handle device removal and insertion, device status changes, etc.

I think you're expecting the problem to be simple, but it's not, and that's not NetworkManager's fault.