On Thu, 2009-06-25 at 13:26 -0500, Bryan Duff wrote: > Is there anyone going forward with this?
Not at this time, beyond projects like cnetworkmanager. > It would be useful for non-X or non-KDE/GNOME setups. And if people > do think it's worth doing (I do) then what is the best path? Yes, it's worthwhile, and is something that should really be done. The main obstacle is currently time. > 1) Split nm-applet into nm-client-lib (backend - with dbus calls) and > gnome based nm-applet, then create an nm-cli. > - I like this option the most because this should re-use a lot of > code (libnm_* for example). This probably isn't the best approach. First off, the users of a CLI client aren't likely to care much about nm-applet. Second, a CLI client and nm-applet can certainly co-exist, and most of what nm-applet does isn't interesting to a CLI client. Thus, I think that the CLI client should probably be written from scratch, *but* using libnm-glib (as nm-applet does too) as a base to make things go more quickly. See the nm-tool sources for how this sort of thing works. > 2) Or something I haven't thought of. > > I've seen a couple partial implementations of a NM cli, but they all > use python (often poorly), and I think that's unnecessary. Hopefully > I'm late to the party and something is already being done about this. The use of python for cnetworkmanager, which while it does make development a *lot* quicker, is a blocker for most of the people that I'd consider prime candidates for a CLI client. The target for a CLI client are users of headless machines that don't necessarily run a GUI, or even casual users of a desktop that spend most of their time in a terminal, or for those users of a DE (enlightenment, XFCE) that don't yet have a native GUI client. Implementation -------------- I don't think the CLI client should provide a user-settings service. nm-applet (or the KDE Solid plugin) does just fine here, and since that service has to be running *all* the time, a CLI client isn't suitable anyway since it runs and quits and runs and quits. However, the system settings service *is* always running, and thus it's easy for the CLI client to use it. Even if the CLI client was used while nm-applet (or the Solid plugin) was running, it could still tell NM to activate any of the user connections just like it would tell NM to activate system connections. So, I believe the CLI client would simply provide these functions: 1) Activate/Deactivate connections provided by the user and system settings services 2) Show network status, including device status, IP config, scan list, etc, much like nm-tool does now 3) Connect to new wifi networks by creating a new system-settings connection for that AP Even those 3 would be a huge win, and the client could be extended later. It can't be perfect from the start. But we need help doing this, and we can certainly provide some guidance on how to get there. Neither I nor Tambet has the time to do this right now, given the other NM features that are currently in-process. But it's a pretty straightforward thing and would be a great intro to the NM APIs and programming in general if somebody wanted to take it up. Dan _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list