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

[Raphael Kubo da Costa]

Gyuyoung Kim <gyuyoung.kim at samsung.com> 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