Announcing ConnMan.net [LWN.net]

Announcing ConnMan.net

Posted Jun 24, 2009 16:11 UTC (Wed) by nirik (subscriber, #71)
In reply to: Announcing ConnMan.net by wstephenson
Parent article: Announcing ConnMan.net

cnetworkmanager?

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

to post comments

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.