Re: New libgtop maintainer

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>

On Sun, Aug 11, 2013 at 1:45 PM, Jasper St. Pierre <jstpierre mecheye net>

On Fri, Aug 9, 2013 at 4:31 PM, Robert Roth <robert roth off gmail com>

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

It took a while to figure out how everything was generated and pieced

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]