Kids can be so crurl: Lead dev unchuffed with Google's plan to remake curl in its own image
'Why use a copy when the original is free, proven and battle-tested?'
Google is planning to reimplement parts of libcurl, a widely used open-source file transfer library, as a wrapper for Chromium's networking API – but curl's lead developer does not welcome the "competition".
Issue 973603 in the Chromium bug tracker describes libcrurl,"a wrapper library for the libcurl easy interface implemented via Cronet API".
Cronet is the Chromium network stack, used not only by Google's browser but also available to Android applications.
The rationale is that:
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.
The Google engineer also believes that "it may also be desirable to develop a 'crurl' tool, which would potentially function as a substitute for the curl command in terminal or similar processes. This would be useful to troubleshoot connection issues or test the functionality of the Chrome Network Stack in a easily [sic] reproducible manner."
Daniel Stenberg, lead developer of curl, has his doubts:
Getting basic functionality for a small set of use cases should be simple and straight forward. But even if they limit the subset to number of functions and libcurl options, making them work exactly as we have them documented will be hard and time consuming.
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!
The real issue, though, is not so much Google's ability to do this – after all, as Stenberg noted: "If they just put two paid engineers on their project they already have more dedicated man power than the original libcurl project does."
Rather, it is why Google is reimplementing libcurl as a wrapper for its own APIs rather than simply using libcurl and potentially improving it for everyone.
"I think introducing half-baked implementations of the API will cause users grief since it will be hard for users to understand what API it is and how they differ," Stenberg wrote. He also feels that naming the Chromium versions "libcrurl" and "crurl" will cause confusion as they "look like typos of the original names".
Stenberg is clear that the Google team is morally and legally allowed to do this, since curl is free and open source under the MIT licence. But he added:
We are determined to keep libcurl the transfer library for the internet. We support the full API and we offer full backwards compatibility while working the same way on a vast amount of different platforms and architectures. Why use a copy when the original is free, proven and battle-tested since years?
Over to you, Google.®