<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 30, 2017 at 2:02 PM, Colin Walters <span dir="ltr"><<a href="mailto:walters@verbum.org" target="_blank">walters@verbum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Oct 30, 2017, at 07:43 AM, Neal Gompa wrote:<br>
> * Using C++ makes glib2 usage mostly pointless, as glib2 is by and<br>
> large replaced by the C++ STL. The only advantage of GLib2 is GObject<br>
> Introspection<br>
<br>
</span>Not quite; there's also the main event loop, which is also tied into<br>
infrastructure like file monitoring (used today in libdnf to monitor<br>
the rpmdb), and what are effectively "sub-libraries" in libglib<br>
like GDBus.   For example today dnf talks to NM via pydbus:<br>
<a href="https://github.com/rpm-software-management/dnf/blob/master/dnf/util.py#L261" rel="noreferrer" target="_blank">https://github.com/rpm-<wbr>software-management/dnf/blob/<wbr>master/dnf/util.py#L261</a><br>
which is currently synchronous, but any nontrivial usage<br>
requires a main loop (which pydbus uses glib's most commonly).<br>
<br>
And the whole "async" infrastructure in GTask is based on this.<br>
Now, libdnf today is mostly synchronous, which is OK.  We could<br>
keep it that way.<br></blockquote><div>Libdnf will most likely remain synchronous,</div><div>but thanks for bringing this topic up.</div><div>Making another note...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In fact for various reasons we're highly likely at some point<br>
in the future to change rpm-ostree to mostly use librpm/libdnf<br>
from a subprocess.<br>
<br>
One of those reasons is that librepo doesn't currently use any<br>
of the GIO bits, notably GCancellable:<br>
<a href="https://github.com/projectatomic/rpm-ostree/issues/897#issuecomment-318427563" rel="noreferrer" target="_blank">https://github.com/<wbr>projectatomic/rpm-ostree/<wbr>issues/897#issuecomment-<wbr>318427563</a><br>
<br>
This doesn't matter for a command line tool, but it matters a lot<br>
for a daemon.  So by changing our libdnf to be in a subprocess we're<br>
basically reworking the architecture to be daemon → internal command line.<br>
<br>
But, even if we do this, we'll need to do things like have progress<br>
on downloads be emitted via some internal messaging framework<br>
(probably private DBus socket).  I think that'll be fine if things are generally<br>
synchronous in libdnf, but if we're talking about redoing libdnf<br>
I think we need to keep these high level architectural bits in<br>
mind and not just focus on the programming language.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
Rpm-ecosystem mailing list<br>
<a href="mailto:Rpm-ecosystem@lists.rpm.org">Rpm-ecosystem@lists.rpm.org</a><br>
<a href="http://lists.rpm.org/mailman/listinfo/rpm-ecosystem" rel="noreferrer" target="_blank">http://lists.rpm.org/mailman/<wbr>listinfo/rpm-ecosystem</a><br>
</div></div></blockquote></div><br></div></div>