Re: [webkit-efl] Dropping support for the libcurl network backend
Hello ryuan, I'm sorry. I don't understand well what is your point. Anyway, if #if USE(SOUP) macro is problem, we can distinguish libsoup / libcurl file for each ewk file. For example, ewk_cookie_soup.cpp ewk_cookie_curl.cpp and so on. AS you know, ewk_auth already use this. We can select which file is built by make file. How do you think about it ? - Gyuyoung. ------- Original Message ------- Sender : ryuan Choi<ryuan.choi@gmail.com> Date : 2012-02-02 11:14 (GMT+09:00) Title : Re: [webkit-efl] Dropping support for the libcurl network backend Hi, guys. I'm not sure whether we can drop libcurl when libsoup is better. If I am right, ecore have options to support glib. I think that It means that glib is not mandatory on Efl world. Can we declare that webkit/efl is only available when ecore is compiled with glib? -- Ryuan Choi 2012년 2월 2일 오전 10:38, Gyuyoung Kim <gyuyoung.kim@samsung.com>님의 말: Hello Kubo, 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 ? -- Gyuyoung. ------- Original Message ------- Sender : Raphael Kubo da Costa<kubo@profusion.mobi> Date : 2012-02-02 01:44 (GMT+09:00) Title : [webkit-efl] Dropping support for the libcurl network backend Hi there. 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 http://profusion.mobi _______________________________________________ webkit-efl mailing list webkit-efl@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl _______________________________________________ webkit-efl mailing list webkit-efl@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl
Hello gyuyoung, Sorry about your confusion. I like libsoup backend for WebKit/Efl. But we need to support libcurl backends if some Efl guys want to use WebKit/Efl on ecore which doesn't support glib. It's just my two cents. And my assumption is because glib is not mandantory library for building ecore. Cleanup like you mentioned is better for me. - Ryuan Choi 2012년 2월 2일 오전 11:50, Gyuyoung Kim <gyuyoung.kim@samsung.com>님의 말:
Hello ryuan,
I'm sorry. I don't understand well what is your point.
Anyway, if #if USE(SOUP) macro is problem, we can distinguish libsoup / libcurl file for each ewk file. For example, ewk_cookie_soup.cpp ewk_cookie_curl.cpp and so on. AS you know, ewk_auth already use this. We can select which file is built by make file. How do you think about it ?
- Gyuyoung.
------- Original Message ------- Sender : ryuan Choi<ryuan.choi@gmail.com> Date : 2012-02-02 11:14 (GMT+09:00) Title : Re: [webkit-efl] Dropping support for the libcurl network backend
Hi, guys.
I'm not sure whether we can drop libcurl when libsoup is better.
If I am right, ecore have options to support glib. I think that It means that glib is not mandatory on Efl world.
Can we declare that webkit/efl is only available when ecore is compiled with glib?
-- Ryuan Choi
2012년 2월 2일 오전 10:38, Gyuyoung Kim <gyuyoung.kim@samsung.com>님의 말:
Hello Kubo,
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 ?
-- Gyuyoung.
------- Original Message ------- Sender : Raphael Kubo da Costa<kubo@profusion.mobi> Date : 2012-02-02 01:44 (GMT+09:00) Title : [webkit-efl] Dropping support for the libcurl network backend
Hi there.
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 http://profusion.mobi
_______________________________________________ webkit-efl mailing list webkit-efl@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl _______________________________________________ webkit-efl mailing list webkit-efl@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl
participants (2)
-
Gyuyoung Kim
-
ryuan Choi