Re: New libgtop maintainer

[drago01 <drago01 gmail com>]

On Sun, Aug 11, 2013 at 1:46 PM, Jasper St. Pierre
<jstpierre mecheye net> wrote:
> On Sun, Aug 11, 2013 at 7:28 AM, Robert Roth <robert roth off gmail com>
> wrote:
> > On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre <jstpierre mecheye net>
> > wrote:
> > > On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth <robert roth off 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.