cURL 创始人 Daniel Stenberg 发文指出谷歌正在实现自己的 curl。

cURL 是一个网络数据传输项目，通常说 cURL 是指 curl 命令行工具，它支持 DICT、FILE、FTP、FTPS、Gopher、HTTP、HTTPS、IMAP、IMAPS、LDAP、LDAPS、POP3、POP3S、RTMP、RTSP、SCP、SFTP、SMB、SMBS、SMTP、SMTPS、Telnet 与 TFTP 等协议，而 curl 的底层使用的是 libcurl 库，libcurl 与 curl 组成了 cURL 项目。

Chromium bug 团队近日表示他们将基于 Chromium 网络栈 Cronet 实现一个名为 libcrurl 的库，用来提供部分 libcurl API。对于 Daniel 来说，谷歌很可能是要实现一个他们自己的 curl，所以后边可能出现一个基于 libcrurl 的“crurl”。

至于为什么要这么做，Chromium bug 团队表示，使用 Cronet 实现 libcurl 将允许开发人员使用 Chrome 网络栈的实用程序，而无需学习新的接口及其相应的工作流。理想情况下，这将增加 Cronet 的可用性，并通过第一方或第三方应用全面改进 Cronet 的采用。

Daniel 觉得谷歌这样的逻辑是有道理的：“理想情况下，Google 最终解决此问题的团队会发现并修复我们的代码和 API 中的问题，这可以改进 curl，同时也可以使更多用户了解 libcurl 与其 API。而如果工程师最终实现了一个比 libcurl 更好的库，并且使用相同的 API，那么开发者就可以直接选择他们认为更好的库。”

然而问题是，Daniel 认为这项工作并不简单，首先是 libcurl API 已经开发了近 20 年，它的许多功能、选项和微妙的行为可能无法轻易地直接模仿；另一方面，Cronet 与 libcurl 的工作方式完全不同，因此需要投入足够多的人力与时间来将 libcurl API 整合到 Cronet 上。

“我认为引入 API 不成熟的实现会给开发者带来困扰，因为他们很难理解它是个什么 API 以及与 libcurl 的区别”，像前边说的，Daniel 认为如果没有投入很大的工作量，那 libcrurl 不可能提供兼容 libcurl 的 API，而这种分裂将导致文档问题，甚至连基本的项目名都可能混淆，因为“libcrurl”/“crurl”与原本的“libcurl”/“curl”太像了，使用者可能误认为它们只是拼写错误。

虽然说理解谷歌的做法，并且也知道他们有权利这么去做，但是 Daniel 文章最后还是发出了疑问：curl 支持完整的 API，提供完全向后兼容性，同时在大量不同的平台和架构上可以相同的方式工作，并且免费，还经过多年实战考验，那么在这种情况下，开发者有什么理由要去使用另一个翻版的呢？

有意思的是，Daniel 的这篇博客评论中有人将谷歌的这一动作与微软 90 年代的“拥抱、扩展再毁灭”策略联系了起来。