Yesterday, Daniel Stenberg, the lead developer of curl announced that Google is planning to reimplement curl in libcrurl and it will be renamed as libcurl_on_cronet.
To be renamed to "libcurl_on_cronet":https://t.co/FcTRwkYZYW
— Daniel Stenberg (@bagder) June 20, 2019
The official blog post reads, “The Chromium bug states that they will create a library of their own (named libcrurl) that will offer (parts of) the libcurl API and be implemented using Cronet.”
Daniel Stenberg explains the reason for reimplementation, “Implementing libcurl using Cronet would allow developers to take advantage of the utility of the Chrome Network Stack, without having to learn a new interface and its corresponding workflow. This would ideally increase ease of accessibility of Cronet, and overall improve adoption of Cronet by first-party or third-party applications.”
According to him, the team might also hope that 3rd party applications can switch to this library without the need for switching to another API.
So if this works then there is a possibility that the team might also create “crurl” tool which then will be their own version of the tool using their own library.
Daniel Stenberg states in the post, “In itself is a pretty strong indication that their API will not be fully compatible, as if it was they could just use the existing curl tool…”
He writes, “As the primary author and developer of the libcurl API and the libcurl code, I assume that Cronet works quite differently than libcurl so there’s going to be quite a lot of wrestling of data and code flow to make this API work on that code.”
The libcurl API is quite versatile and has developed over a period of almost 20 years. There’s a lot of functionality, options and subtle behavior that may or may not be easy to mimic.
If the subset is limited to a number of functions and libcurl options and they are made to work exactly the way they have been documented, then it could be difficult as well as time-consuming.
He writes, “I don’t think applications will be able to arbitrarily use either library for a very long time, if ever. libcurl has 80 public functions and curl_easy_setopt alone takes 268 different options!”
Read Also: Cisco merely blacklisted a curl instead of actually fixing the vulnerable code for RV320 and RV325
According to Stenberg, there’s still no clarity on API/ABI stability or how are they planning to ship or version their library.
Stenberg writes, “There’s this saying about imitation and flattery but getting competition from a giant like Google is a little intimidating. If they just put two paid engineers on their project they already have more dedicated man power than the original libcurl project does…”
So, the team from Google’s end finds and fixes issues in the code and API such that curl improves. This makes more users aware of libcurl and its API and the team behind curl make it easier for users and applications to do safe and solid Internet transfers.
According to Stenberg, applications need to be aware of the APIs they work with to avoid confusion. He also highlighted that users might have been confused because of the names, “libcrurl” and “crurl” as they appear to be like typos.
He added, “Since I don’t think “libcrurl” will be able to offer a compatible API without a considerable effort, I think applications will need to be aware of which of the APIs they work with and then we have a “split world” to deal with for the foreseeable future and that will cause problems, documentation problems and users misunderstanding or just getting things wrong.”
“Their naming will possibly also be the reason for confusion since “libcrurl” and “crurl” look so much like typos of the original names,” he said.
To know more about this news, check out the blog post by Daniel Stanberg.
Read Next
Google Calendar was down for nearly three hours after a major outage
How Genius used embedded hidden Morse code in lyrics to catch plagiarism in Google search results
Google, Facebook and Twitter submit reports to EU Commission on progress to fight disinformation
