Bug 77874

Summary: [EFL] Drop support for the Curl network backend.
Product: WebKit Reporter: Raphael Kubo da Costa (:rakuco) <rakuco>
Component: WebKit EFLAssignee: Raphael Kubo da Costa (:rakuco) <rakuco>
Status: RESOLVED FIXED    
Severity: Normal CC: eric, gyuyoung.kim, gyuyoung.kim, leandro, lucas.de.marchi, s.hak.lee, ssungmai.kim
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 77341    
Attachments:
Description Flags
Patch
none
Patch for landing none

Description Raphael Kubo da Costa (:rakuco) 2012-02-06 07:55:04 PST
[EFL] Drop support for the Curl network backend.
Comment 1 Raphael Kubo da Costa (:rakuco) 2012-02-06 07:58:13 PST
Created attachment 125647 [details]
Patch
Comment 2 Gyuyoung Kim 2012-02-06 08:30:55 PST
Comment on attachment 125647 [details]
Patch

Attachment 125647 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/11432332
Comment 3 Gyuyoung Kim 2012-02-06 18:24:46 PST
I wanna decide to remove this libcurl support after profiling libcurl. The result will be updated soon.
Comment 4 Eric Seidel (no email) 2012-02-07 16:10:14 PST
Comment on attachment 125647 [details]
Patch

I'm happy to rubber-stamp this, except it seems to break the efl-ews.
Comment 5 Eric Seidel (no email) 2012-02-07 16:10:46 PST
Please make sure to follow-up by removing the actual curl support files if EFL was the last client of curl.
Comment 6 Leandro Pereira 2012-02-08 10:31:44 PST
(In reply to comment #5)
> Please make sure to follow-up by removing the actual curl support files if EFL
> was the last client of curl.

The WinCairo port seems to use cURL. The other network backend used by the Windows port is CFNetwork, which still seems to be proprietary.
Comment 7 Raphael Kubo da Costa (:rakuco) 2012-02-09 19:02:10 PST
Created attachment 126431 [details]
Patch for landing
Comment 8 Gyuyoung Kim 2012-02-09 21:44:03 PST
If many guys agree on removing curl port from WebCore, I also agree with this removal. But, I'm still wanna decide this removal after libcurl performance profiling in EFL port. I was told that the performance profiling result will be reported by next week.
Comment 9 Sungman Kim 2012-02-13 03:43:36 PST
I did comparing loading test with libsoup and libcurl last week. 
Total test site number is 96 and 
our test result is below.
Average :
libsoup 4.93sec
libcurl 5.51sec
Libcurl is better than libsoup just in case of 6 sites.
Libcurl's performance is not better.
These are our test results.
Thank you.
Comment 10 Raphael Kubo da Costa (:rakuco) 2012-02-13 05:11:20 PST
(In reply to comment #9)
> I did comparing loading test with libsoup and libcurl last week. 
> Total test site number is 96 and 
> our test result is below.
> Average :
> libsoup 4.93sec
> libcurl 5.51sec
> Libcurl is better than libsoup just in case of 6 sites.
> Libcurl's performance is not better.
> These are our test results.
> Thank you.

OK, thanks. For posterity, it would be good to know more about the methodology of these tests (ie. what exactly was tested and how).
Comment 11 Raphael Kubo da Costa (:rakuco) 2012-02-13 05:31:08 PST
Committed r107562: <http://trac.webkit.org/changeset/107562>
Comment 12 Sungman Kim 2012-02-13 17:01:46 PST
OK. We added test codes for page logging loading time including some exception handling.
If we start browser app. then it read the url lists for test and memorize loading start time each url loading start. When the loading is finished for one site, loading time is calculated and automatically start loading next url.
For using these methods, we tested about 96 urls each 6 times. 
Each Libcurl and Libsoup devices are started loading synchronously. (actually a little term is exist)
Thank you.