[webkit-efl] Dropping support for the libcurl network backend

[Gyuyoung Kim]

Hello Kubo,

>> I don't see performance as a single determinant factor here, but I'd
>> love to see some data from your colleagues.
 
Yes, my coworkers are going to start curl profiling vs. libsoup. If curl performance is better,
we need to consider which network backend EFL port uses. If there is no difference from performance and features of view,
I think it is better to use curl instead of libsoup in order to remove glib dependency. If so, my co-workers are willing to maintain libcurl port
or participate in libcurl port.
 
In addtion, we need to consider Ryuan's comment. If some guys don't want to use glib dependency, how to connect network via libsoup ?

p.s Please ignore my previous email that patch receiver is wrong.

BR,
Gyuyoung.


------- Original Message -------
Sender : Raphael Kubo da Costa<kubo at profusion.mobi>
Date : 2012-02-02 21:12 (GMT+09:00)
Title : Re: [webkit-efl] Dropping support for the libcurl network backend

Gyuyoung Kim writes:

> 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 ?

I don't see performance as a single determinant factor here, but I'd
love to see some data from your colleagues.

However, the point I'm trying to make is that even if curl's performance
is currently better, I currently see more value in improving the soup
backend to make it at least close to curl's performance.

If you look at the commit logs for Source/WebCore/platform/network/curl,
you will see it is not being actively maintained by anyone. And if you
look at its sources, you will see many methods it implements are simply
stubs with no functional code. Which brings us to the second point you
mentioned, features: there is code in ewk which only works with the
libsoup backend and there are many more features currently not implemented
in the backend itself.

Last but not least, if most of the people working on the EFL port are
already using the libsoup backend and even the EWS bot only tests the
changes in with the soup backend, I don't see the current situation
changing, which means we will keep working on adding features with one
backend in mind while the one just rots.

-- 
Raphael Kubo da Costa
ProFUSION embedded systems
http://profusion.mobi

_______________________________________________
webkit-efl mailing list
webkit-efl at lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-efl