Re: NM CLI
- From: Dan Williams <dcbw redhat com>
- To: Bryan Duff <duff0097 gmail com>
- Cc: networkmanager-list gnome org
- Subject: Re: NM CLI
- Date: Wed, 01 Jul 2009 09:27:11 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]