[webkit-efl] Dropping support for the libcurl network backend
gyuyoung.kim at samsung.com
Wed Feb 1 17:38:58 PST 2012
I agree with your opinion that soup macro clutter is growing. However, we don't test/profile which one is better yet.
If libcurl's performance or features are better than soup, application may want to use libcurl instead of libsoup.
I heard my co-workers have a plan to profile both libcurl and libsoup. Why don't we decide if we drop libcurl after the profiling ?
------- Original Message -------
Sender : Raphael Kubo da Costa<kubo at profusion.mobi>
Date : 2012-02-02 01:44 (GMT+09:00)
Title : [webkit-efl] Dropping support for the libcurl network backend
We've supported building webkit-efl with both the curl and libsoup
network backends for quite some time.
By default, the port builds with the libsoup backend, the layout tests
(and the skipped list) assume the libsoup backend is used, and there is
code in ewk (ewk_cookies, ewk_network and ewk_auth, for example) which
only works in the soup backend.
Given all that, the fact that the #if USE(SOUP) clutter is growing and
the way these #ifdefs are causing bug 77341 to be more troublesome to
integrate than neeed, I'm inclined to drop support for the curl backend.
The only current drawback I see is that we'd force the dependency on
unstable GNOME libraries for things to work.
Thoughts? Does anyone desperately need the libcurl backend?
Raphael Kubo da Costa
ProFUSION embedded systems
webkit-efl mailing list
webkit-efl at lists.webkit.org
More information about the webkit-efl