Re: [Lxde-list] About LXNM current status and plan in the future

[Christoph W. <chr...@go...>]

Am Donnerstag, den 18.06.2009, 01:41 +0800 schrieb Fred Chien:
> Christoph Wickert 提到:
> > Am Donnerstag, den 18.06.2009, 00:10 +0800 schrieb Fred Chien:
> >   
> >> Christoph Wickert:
> >>     
> >>> Am Dienstag, den 16.06.2009, 11:22 +0800 schrieb Fred Chien:
> >>>
> >>>   
> >>>       
> >>>> So the project will has three parts to be maintained:
> >>>> 1. lxnm (LXNM Daemon and command line utility - lxnetctl)
> >>>> 2. lxpanel-netstat (LXPanel plugin)
> >>>> 3. lxnm-applet (standalone applet)
> >>>>
> >>>> For the current version in SVN, lxnm can be working now, we can using
> >>>> lxnetctl utility to connect to lxnm daemon to control our networking
> >>>> devices and get informations include ethernet and wireless interface.
> >>>>
> >>>> BTW, I am now working on lxnm-applet to implement a graphical LXNM
> >>>> client to display and control network devices.
> >>>>     
> >>>>         
> >>> Any particular reason not to use NeworkManager and write two tools of
> >>> their own instead? Why not make lxnm-applet work on top of
> >>> NetworkManager? NM already provides dbus and commandline interfaces and
> >>> a stable API.
> >>>
> >>> Regards,
> >>> Christoph
> >>>
> >>>   
> >>>       
> >> Agree so. NetworkManager has full functions to support network
> >> connections operations, we don't have any reason to rewrite a new
> >> utility instead of that. There is a problem that NetworkManager is using
> >> dbus to communicate between daemon and applet, and also it has some
> >> complicated design cause it is heavy and not suitable for some low
> >> resource machines.
> >>     
> >
> > LXDE will rely on dbus anyway, so IMO dbus is no problem. IMO we really
> > need dbus, how else would you advertise the current connection status to
> > apps that are aware of it.
> >
> >   
> Well, LXDE will support dbus, but not necessary to rely on dbus. Because
> we will try to do anything to avoid to use dbus to make it has less
> dependencies. 

lxsession already relies on dbus, so the whole LXDE desktop needs it.
Requiring dbus for LXNM wouldn't add a single dependency, except to LXNM
itself.

> It's undeniable that dbus is a very powerful IPC
> implementation, it can do a lot, but it is not good for all situation.
> If we just need to transmit simple and short data, using unix-socket is
> easiler and faster. Why we need to use dbus to copy and handle our data
> twice for simple communication model?

Because we avoid polling and open file handles. Because with dbus we can
announce the network status to apps. Can we do the same with LXNM and a
unix-socked?

> >> Besides, NetworkManager is it is difficult to implement some features
> >> just like mesh networking for NetworkManager, so we need flexible
> >> architecture. That's why rewrite a new one.
> >>     
> >
> > Mesh is no problem here, happily using on my XO with NM. What exactly is
> > the problem with meshing? Can you tell me more about the other problems
> > you see?
> >
> >   
> Of course mesh is working fine with NM, I mean we cannot easy to use NM
> to control and configure mesh or other networking stuffs. The problem is
> how can add those new features to NM? I think it is not easy and fast to
> implement. 

NM already supports mesh to a certain degree and can be extended through
plugins. I'm sure it's easier to get the missing mesh bits into NM than
writing something new from scratch.

> And then we can see GUI design issue. In fact,
> NetworkManager's UI is just a commandline-like GUI, it's geek's toy
> rather then normal user's tool.

I absolutely disagree, I think the nm-applet is as simple as possible.
Take a look at wicd, wifi-radar or airconfig: They all have more options
and more buttons, *these* are the nerd tools compared to nm-applet.

>  You may think it is a Frontend UI issue,
> but don't forget all of functions of frontend rely on backend daemon
> support. :-)

A backend supporting a lot of functions is a good thing, a frontend
presenting them all to the user not necessarily.
> 
> Fred

Regards,
Christoph