Re: [GNUnet-developers] libwget2

[ng0]

Hi,

Schanzenbach, Martin transcribed 3.7K bytes:
> So. Christian is a bit better with those things but I have just taken a brief 
> look into wget2.
> The thing is that curl has a "nice" way of having your own scheduling (using 
> curl_multi_perform etc).
> As far as I can see wget2 (apart from having a _huge_ kitchensink as well) 

Wasn't the kitchensink one of the reasons to consider switching away from curl? 
Now I'm curious
for what Christian sees in wget2.

> does internal multithreading for downloads in connections and almost 
> exclusively has blocking, synchronous calls.
> Even in their async example the calls are blocking! See 
> https://github.com/rockdaboot/wget2/blob/master/examples/http_multi_get.c.
> (Maybe there is way to implement proper async calls; possibly using 
> wget_net*: 
> https://gnuwget.gitlab.io/wget2/reference/group__libwget-net.html#ga71e02092659a35a26c8ac4cdfec23854)

And this is bad for us in GNUnet because we require non-blocking asyc calls?
You are more experienced in the field than I am and longer involved here.

> I don't see this playing nice with the GNUnet scheduler.
> To me, there does not seem to be a major advantage of wget2 over curl.

Okay.

> I guess there is a packaging issue between curl and gnurl (I don't have 
> context atm sorry) 

It's more of a system-integration problem than a packaging problem (see links 
below for more).
I manage to do releases of gnurl without much work now, could be better only 
with having to
maintain gnurl in the first place.

> and I am also not happy with the gnurl dependency, but the reasoning behind 
> it is clear.
> Looking at wget2, however, I personally do not see any advantage for GNUnet 
> to integrate it. Actually, I see technical limitations that would make this 
> quite difficult without modifying wget2.

Quite difficult is not impossible though, but so far libgnurl seems to be 
easiest solution.

> 
> BR
> Martin

I hoped for a one time effort to fix the outstanding long-term works on 
libgnurl, but reading this
it seems to me that wget2 needs more evaluation? Christian originally mentioned 
wget2 as an alternative
so there must be something to it.

The recent libgnurl releases were only 1 - 12 hours of work including checking 
and fixing merges,
but properly integrating it (and there GNUnet!) into Guix is something I hoped 
to avoid fixing.

- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25240
- https://lists.gnu.org/archive/html/guix-devel/2017-01/msg00516.html
There's no easy solution to it as can be seen in my previous attempts, 
including:
- https://lists.gnu.org/archive/html/guix-devel/2018-01/msg00347.html


As you wrote, Christian should have more insight and I still wish to read or 
hear more in depth
why Christian considered wget2. Nevertheless, this is already more than 
Christian told me before.
Thanks!


> > On 22. Mar 2018, at 19:13, ng0 <address@hidden> wrote:
> > 
> > Hi,
> > 
> > remind me again: What exactly is in the way (besides us making relevant 
> > changes in GNUnet)
> > to make use of libwget2 as a successor to gnURL?
> > Someone knew it and had just grumpy opinions on the wget.h ... but besides 
> > "omg it is long",
> > what can we do in cooperation with wget2 to get to a point where we can 
> > embrace wget2?
> > 
> > We have this long standing ridiculous issue in Guix with curl and gnurl, 
> > and if wget2 would
> > just work and function differently than curl (CURL_CA_PATH is the issue) it 
> > would be so much
> > easier to finally get this integrated. "on first run download the hostlist" 
> > "oh, excuse me
> > we first have to crash into the wellknown kitchensink with curl/gnurl".
> > I'd rather invest time in trying to get wget2 ready than to continue 
> > merging from curl and
> > having dependency on their problems (which are somewhat unique to the 
> > Guix+GuixSD situation.
> > --
> > A88C8ADD129828D7EAC02E52E22F9BBFEE348588
> > https://n0.is
> > 
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/gnunet-developers
> 
> 
> - Martin
> 
> GPG: 3D11063C10F98D14BD24D1470B0998EF86F59B6A
> 



-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is