[Top][All Lists]

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

Re: [GNUnet-developers] hypothetical gnurl successor capabilities

From: Daniel Golle
Subject: Re: [GNUnet-developers] hypothetical gnurl successor capabilities
Date: Mon, 27 May 2019 23:54:08 +0200
User-agent: Mutt/1.11.4 (2019-03-13)


On Mon, May 27, 2019 at 10:44:23PM +0200, Christian Grothoff wrote:
> On 5/27/19 10:17 PM, address@hidden wrote:
> > Hi,
> > 
> > offlist and sometimes on-list we've been talking over the last
> > years now and then about the possibility of replacing gnurl.
> > 
> > 2 choices were given so far: "let's help curl or wait until
> > they have fixed what makes gnurl necessary"; ie not a task for
> > one afternoon, touches many parts of curl", and wget2; which
> > was found to be comparable to curl at the moment (too big).
> I should mention that the libwget maintainers are active and engaging
> with MHD and also asked me personally what changes they would have to
> make to libwget to make it suit our purposes, and that they are
> generally _eager_ to make this happen. I've had first discussions with
> them on what changes I primarily would need to see, and given time and
> opportunity the discussion left me quite optimistic that this may
> actually happen.  So I wouldn't look for a 3rd choice, but rather we
> should work with libwget2 in terms of clarifying requirements (splitting
> the library to make the core we'd have to link to smaller, and adding
> event loop support were the two main issues I already mentioned to them)
> and/or even directly working with them on this (coding, testing,
> integration) is thus a good way to approach this.

I guess you are aware of libuclient[1]? Writing gnutls bindings for
libustream [2] would not be hard ;) Please take a look at the code
(it's really not a lot) and tell me if you believe it can be useful,
in that case I'd volunteer to implement the gnutls support for it.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]