View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005131 | GNUnet | other | public | 2017-08-27 18:18 | 2018-06-07 23:35 |
| Reporter | nikita | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Fixed in Version | 0.11.0pre66 | ||||
| Summary | 0005131: look into GNU wget2 as a successor to our dependency on gnURL | ||||
| Description | Taken from https://lists.gnu.org/archive/html/gnunet-developers/2017-08/msg00005.html On 08/24/2017 10:31 AM, ng0 wrote: > Hi everyone, > > With the release of 7.55.1-3 I am positive that I achieved one of the > initial goals of gnURL: cURL and gnURL should be able to exist on one > system (without the need for downstream packagers to apply further hacks). > > So, what's next? > > * New Features? > Christian concluded the initial announcement post of gnURL with: > "However, we're happy to add new features relating to this core > subset and might be easier to convince than the cURL developers." > > So, what features would you like to see without introducing too > much maintenance burden you have to debug? Is there anything > cURL doesn't do you'd like to see or change? Well, what I primarily had in mind was making curl pluggable. We should dlopen() libraries that support protocols, both in terms of transport protocol (HTTP/FTP/etc.) and crypto (OpenSSL/GnuTLS/etc.). That way, libgnurl itself would not link against the world plus a kitchen sink, but only against dependencies we actually need. That said, with GNU (lib)wget2, there is a competitor for cURL (at least the HTTP-part) on the horizon, and GNU wget2 is already working on using GNU libmicrohttpd for their test suite, so I think we should take a closer look at it to see if it might be a better alternative to cURL and gnURL before investing significant efforts into gnURL. | ||||
| Tags | No tags attached. | ||||
|
|
Christian, can you expand on what would qualify wget2 as usable for us and how we can determine that it is? All I know right now is that wget2 is in early stages. |
|
|
I just checked, and OMG, what a header. wget2.h defines _a lot_, way more crazy than curl or MHD. That itself is not bad, but the current API has lots of _global_ state, which is terrible. So we ought to talk to them to see if there is a chance of them eliminating the global state (lots of options about the operation). Without that, I don't think it's realistic. |
|
|
Closing, as libwget2 is clearly inadequate for now. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-08-27 18:18 | nikita | New Issue | |
| 2017-09-25 19:43 | nikita | Note Added: 0012435 | |
| 2017-09-25 19:43 | nikita | Assigned To | => Christian Grothoff |
| 2017-09-25 19:43 | nikita | Status | new => feedback |
| 2017-09-25 19:54 | Christian Grothoff | Note Added: 0012436 | |
| 2017-09-26 22:57 | Christian Grothoff | Relationship added | related to 0005084 |
| 2018-06-07 23:35 | Christian Grothoff | Status | feedback => closed |
| 2018-06-07 23:35 | Christian Grothoff | Resolution | open => no change required |
| 2018-06-07 23:35 | Christian Grothoff | Fixed in Version | => 0.11.0pre66 |
| 2018-06-07 23:35 | Christian Grothoff | Note Added: 0013029 |
