On Sun, Aug 11, 2013 at 1:46 PM, Jasper St. Pierre <jstpie...@mecheye.net> wrote: > > > > On Sun, Aug 11, 2013 at 7:28 AM, Robert Roth <robert.roth....@gmail.com> > wrote: >> >> >> >> >> On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre <jstpie...@mecheye.net> >> wrote: >>> >>> On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth <robert.roth....@gmail.com> >>> wrote: >>>> >>>> Hello everyone, >>>> >>>> Matthias Clasen (mclasen) asked me to write and let you know that I will >>>> be taking over the maintenance of libgtop. >>>> >>>> libgtop is the library used by System Monitor and Control Center (if you >>>> are a developer of an application using libgtop, please let me know) to >>>> query system information, but unfortunately the development has stalled, >>>> the >>>> last release has happened in 2011, almost two years ago. >>>> >>>> My goals for the 3.12 cycle (as we're getting close to the 3.9 freeze, >>>> only for the next cycle) are to review the buglist of the module, and >>>> extend >>>> it to provide library support for various gnome-system-monitor enhancement >>>> requests, but in the meantime keep it simple and fast enough to back the >>>> upcoming Usage application. >>>> >>>> Thanks for reading, >>> >>> >>> I was trying to hack on the libgtop code a little while ago, and I just >>> found it hard to hack on. The code was generated, and it seemed to be put >>> together by this giant mess of perl scripts. >> >> I've also hacked some small features in the libgtop code, and wasn't hard, >> but maybe I took only the low-hanging fruits. Extending existing libgtop >> implementations (meaning include/... and sysdeps/linux/... code) with new >> features looked pretty hassle-free for me. Of course, If there are server >> changes required (I don't know cases when we would need that, I didn't need >> any so far), it might be hard. > > > My case was https://bugzilla.gnome.org/show_bug.cgi?id=663265 > > It took a while to figure out how everything was generated and pieced > together. > >>> >>> So, I wonder if it makes sense to stop generating libgtop and instead >>> just focus on a solid, easily understood codebase. I never really understood >>> why we had a client/daemon split, either; it doesn't seem that we're doing >>> anything too fancy on either side. Is it that we require root for reading >>> some of the files? Should we move to a system DBus service instead? >> >> I guess the client-server split is required for the root access indeed, in >> that case replacing it with a DBUS system service would be an option, but >> seems like libgtop is a server indeed, and can be connected to from the >> network too, and I don't know whether that's possible with DBUS, > > > Hm, I didn't know it was supposed to be connectable from the network. In > fact, when I read the code a little while ago, I swore it only listened on a > UNIX socket. I think we've said that remote DBus is possible, but would take > a considerable amount of work to actually get working. I'm not sure how true > that is nowadays.
No dbus is not a network protocol. It is simply not designed for that kind of use. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
