libcurl 和 libsoup 之间的区别

发布于 2024-09-06 12:53:45 字数 1436 浏览 8 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

╄→承喏 2024-09-13 12:53:45

Libsoup 即将推出,但 libcurl 拥有更好的支持和稳定性。 Lib soup 开发人员欣然承认您应该使用 libcurl。

第四项特别重要,因为即使在 Linux KDE 和 XCF 上,用户也会安装 gnome 相关的库,但当平台独立选项可用时,强制他们使用 gnome 库并不好。

  1. libcurl 更加可移植
  2. libsoup 缺乏对以下内容的支持:代理的 NTLM(代理身份验证:)、GSS、分块响应中的预告片、OpenSSL
  3. libsoup 提供服务器端支持
  4. libsoup 使用 GNOME 相关的库,使其成为不太方便的选择适用于非 GNOME 环境。

“我发现 libsoup 比 libcurl 慢得多。它使用至少 4 倍的 CPU 来通过 HTTP 传输高比特率数据流。我将此归因于对重量级 glib/gobject 结构的过度依赖。伙计,那个东西很慢而且使用起来很痛苦!” ——马特·格伦克

Libsoup is coming along, but libcurl has much better support and stability. Lib soup devs readily admit that you should probably be using libcurl.

The 4th item is especially important because even on Linux KDE and XCF users will install gnome-related libs, but it isn't nice to force them to use the gnome libraries when a platform independent option is available.

  1. libcurl is (far) more portable
  2. libsoup lacks support for: NTLM for proxies (Proxy-Authentication:), GSS, trailers in chunked responses, OpenSSL
  3. libsoup offers server-side support
  4. libsoup is using GNOME-related libs, making it a less convenient choice for non-GNOME environments.

"I found that libsoup is far slower than libcurl. It uses at least 4x the amount of CPU to transfer a high-bitrate datastream over HTTP. I attribute this to the over-reliance on heavy-weight glib/gobject constructs. Man, that stuff is slow and a pain to use!" - Matt Gruenke

生死何惧 2024-09-13 12:53:45

我正在寻找 libsoup 在一个业余爱好项目上实现 API 的服务器端(我正在制作自己的路由器)。

当我满足 GNOME 依赖关系时,基于回调的服务器端代码的简单性似乎不再像以前那样有吸引力。界面足够好,请参见 soup_server_add_handler()

如果您编写 GNOME 应用程序(因此已经可以依赖 GNOME 依赖项),那没关系(对我来说感觉很慢)。

如果您只是编写客户端代码,或者任何需要在没有 GNOME 的情况下工作的代码,请坚持使用curl。

I was looking at libsoup to implement the server side of an API on a hobby project (I was making my own router).

By the time I got through satisfying the GNOME dependencies, the simplicity of the callback based server side code didn't seem as attractive as it once did. The interface is nice enough, see soup_server_add_handler().

If you write GNOME applications (thus can already count on the GNOME dependencies being there), it's okay (it felt sluggish, to me).

If you are just writing client code, or anything that has to work in the absence of GNOME, stick to curl.

眼中杀气 2024-09-13 12:53:45

http://curl.haxx.se/libcurl/libsoup.html

你可能更好如果您想要可移植性和稳定性,请不要坚持使用 libcurl。

http://curl.haxx.se/libcurl/libsoup.html

Your probably better off sticking with libcurl if you want portability and stability.

壹場煙雨 2024-09-13 12:53:45

使用 libsoup 导致我的 rootfs 增加了近 11MB,而 libcurl 只增加了大约 1MB。
这对于存储资源有限的嵌入式系统非常重要。

Using libsoup caused an increase of almost 11MB in my rootfs, where libcurl only added around 1MB.
This is important in embedded systems with limited storage resources.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文