From: JPV <jp...@gm...> - 2011-04-22 04:49:06
|
Hey, If you remember I was the author of the nfblock D-Bus implementation back in the day. I'm still here but really short on free time. Anyway I thought I'd contribute my 2 cents. I looked at Glib when I wrote the code but I still wouldn't follow that route today. That assessment of libdbus makes sense if you're writing a graphical app and already depend on Qt or Glib. But for a small system daemon I don't think Glib or Qt is a desirable dependency or a good fit for the code. Some minimal environments and many embedded ones don't even have Glib. Then you would be unable to use the GUI over the network to remotely control pgld running in a headless server or router. Besides D-Bus can be used for many purposes, not necessarily just for the GUI. The plan was always to use libdbus in the daemon and Glib-Dbus in a GTK GUI. The low level C library may be more detailed and cumbersome (if you're writing object-oriented code and already pretty intimate with a binding's programming patterns) but not more so than libnetfilter_queue for example. The exact same thing could then be said about a Glib-Netfilter binding. Libdbus is also more powerful, smaller and safer than Glib-Dbus. It's just a different view point. Coding a system service running with elevated privileges should not follow the same guidelines and requirements as a Gnome or KDE app IMO. You're bringing in a lot of cruft by introducing Glib or Qt into the core. Feel free to disagree, of course. :) Out of curiosity what broke the D-Bus and how hard would it be to fix? Regards, jpv On 21-Apr-11 21:59, Jim wrote: > I took a quick look at the code and I think that the current dbus > implementation uses the low level C binding which "is probably too > detailed and cumbersome for anything but writing other bindings" > according to the D-Bus wiki. So unless we have a reason to avoid > glibc, I suggest using it for the dbus implementation in pgld. > > My previous suggestion was to use the Qt library (not the graphics, > just the basic stuff) for pgld D-bus communication but I guess it is > not worth having a part of the daemon dependent on Qt. > > On Thu, Apr 21, 2011 at 8:22 PM, jre > <jre...@us... > <mailto:jre...@us...>> wrote: > > On 04/21/2011 07:04 PM, Jim wrote: > > I also have an idea about the dbus daemon and I want to hear your > > opinions. From what I understand we only need DBus for the GUI > so why > > not abandon the low level API and use the Qt D-Bus bindings? If > we can > > add an option to compile pgld whithout the dbus component (for > people > > using pgld on routers etc) then I believe that we can quickly have a > > working implementation which will be easy to maintain and > improve in the > > future. The only downside is that if for some reason we need > dbus for > > something else in the future, people who don't/can't have Qt will be > > excluded from those features. > > I had no look at the dbus implementation yet ... We definitely should > use the Qt bindings in pgl-gui. But I guess it is > possible/necessary to > use other bindings (IIRC they exist both for C, and for the shell) in > pgld and pglcmd. > > In the long run we also /might/ use dbus for pgld <-> pglcmd > communication, but we don't have to worry about that now. > > It was possible to compile nfblock without dbus support. We definitely > need to keep that option. (The Makefile already supports it.) > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and > improve > application availability and disaster protection. Learn more about > boosting > the value of server virtualization. > http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Peerguardian-devel mailing list > Pee...@li... > <mailto:Pee...@li...> > https://lists.sourceforge.net/lists/listinfo/peerguardian-devel > > > > > -- > "The man who trades freedom for security does not deserve nor will he > ever receive either." > -Benjamin Franklin > > > ------------------------------------------------------------------------------ > Fulfilling the Lean Software Promise > Lean software platforms are now widely adopted and the benefits have been > demonstrated beyond question. Learn why your peers are replacing JEE > containers with lightweight application servers - and what you can gain > from the move.http://p.sf.net/sfu/vmware-sfemails > > > _______________________________________________ > Peerguardian-devel mailing list > Pee...@li... > https://lists.sourceforge.net/lists/listinfo/peerguardian-devel |