On Mon, Oct 30, 2017 at 2:02 PM, Colin Walters <[email protected]> wrote:
> 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. > Libdnf will most likely remain synchronous, but thanks for bringing this topic up. Making another note... > 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 >
_______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
