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.
libcurl is (far) more portable
libsoup lacks support for: NTLM for proxies (Proxy-Authentication:), GSS, trailers in chunked responses, OpenSSL
libsoup offers server-side support
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
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.
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.
发布评论
评论(4)
Libsoup 即将推出,但 libcurl 拥有更好的支持和稳定性。 Lib soup 开发人员欣然承认您应该使用 libcurl。
第四项特别重要,因为即使在 Linux KDE 和 XCF 上,用户也会安装 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.
"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
我正在寻找 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.
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.
使用 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.