Christoph Wickert: > 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. > Principle of LXDE is that every component can be use independently from other components of LXDE offering to use LXDE parts with different Unix like system and desktop environment. > 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? > Every LXDE client can use unix-socket to connect to LXNM daemon, LXNM has a information pool to store current network status, apps doesn't need to call polling and open file handles.
In the future, LXNM will has a own library to make developer easy to write their apps to support LXNM. For embedded, smaller and simple system, the desktop environment may run as root. The library can direct all of handle network operation to increase performance rather than call LXNM daemon, it is like X's DRI architecture. GNOME style is make anything to be a own daemon, so they spend most of resource cost on handling IPC communication and heavy IPC implementation produced stuffs(eg, copy memory content with too much times). Using powerful IPC architecture can bring more powerful features, but it will bring other side effect. Even so, if dbus is needed by some apps, we still can add dbus support as a plugin in LXNM for specific purpose. That's my idea for design of next generation of LXNM. >>>> 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. > Maybe my information is poor, i don't know how's NetworkManager supports mesh, whether it is perfect or not, I have no idea. But it is not only mesh, something's like connection sharing, xDSL, 3G, USB network and bluetooth networki implement...etc >> 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. > > I agree that some part of NetworkManager is simple, but not all. For example, I have family and many friends who is not familiar with computer, and I offten popularize the Linux to them, but they always complain the NetworkManger is not easy to configure xDSL(PPPoE) or 3G (Those feature is put on "Modem" in NM, the category is correct, but confused some people who is not familiar). You may can say that NetworkManager support most of those feature, but It doesn't have perfect UI design make all of NM's feature can be easy to use. >> 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 > > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
