On Mon, Oct 30, 2017, at 07:43 AM, Neal Gompa wrote: > * Using C++ makes glib2 usage mostly pointless, as glib2 is by and > large replaced by the C++ STL. The only advantage of GLib2 is GObject > Introspection
Not quite; there's also the main event loop, which is also tied into infrastructure like file monitoring (used today in libdnf to monitor the rpmdb), and what are effectively "sub-libraries" in libglib like GDBus. For example today dnf talks to NM via pydbus: https://github.com/rpm-software-management/dnf/blob/master/dnf/util.py#L261 which is currently synchronous, but any nontrivial usage requires a main loop (which pydbus uses glib's most commonly). And the whole "async" infrastructure in GTask is based on this. Now, libdnf today is mostly synchronous, which is OK. We could keep it that way. In fact for various reasons we're highly likely at some point in the future to change rpm-ostree to mostly use librpm/libdnf from a subprocess. One of those reasons is that librepo doesn't currently use any of the GIO bits, notably GCancellable: https://github.com/projectatomic/rpm-ostree/issues/897#issuecomment-318427563 This doesn't matter for a command line tool, but it matters a lot for a daemon. So by changing our libdnf to be in a subprocess we're basically reworking the architecture to be daemon → internal command line. But, even if we do this, we'll need to do things like have progress on downloads be emitted via some internal messaging framework (probably private DBus socket). I think that'll be fine if things are generally synchronous in libdnf, but if we're talking about redoing libdnf I think we need to keep these high level architectural bits in mind and not just focus on the programming language. _______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
