[webkit-efl] Third-Party Library uses - Was: Re: [E-devel] Deprecating WebKit EFL 1

Dominik Röttsches dominik.rottsches at intel.com
Wed Oct 31 06:30:36 PDT 2012


Hi all,

just my two cents on the third party library remark.

On 10/31/2012 02:03 PM, Gustavo Lima Chaves wrote:
>>> As a related note: although Ecore provides curl/http, WebKit still
>>> > >uses the crap alien that is libsoup. Why not start the Webkit + EFL
>>> > >adding the missing bits to Ecore_Con and then using it natively in
>>> > >WebKit, instead of forcing glib-mainloop integration for nothing?
>> >
>> >I can't but only agree and wish for that to happen soon.
> +1 here. Then it would be just cairo on the gtk land, I guess.

In my opinion such choices should be made based on a wider spectrum of 
criteria than just based on the question of which framework a library 
belongs to.

If you were talking about libsoup for example, as far as I know, Ecore 
Con effectively wraps curl, which then would qualify as an "alien" if 
you like.
Curl hasn't proven to be a very successful backend for the GTK or 
libcurl port. See for example WebKit bugs 77874 and 68160. Implementing 
things like WebTiming where you need accurate timing information about 
events happening inside the HTTP library might not be possible without 
changes to libcurl/ecore con.

I am not saying it's impossible to use WebKit EFL with Ecore, my point 
is, what's wrong with using non-framework libraries if they solve a 
problem and the choice is efficient in terms of overall effort and time 
necessary to maintain and run it.

Similarly, maintaining yet another separate 2D graphics backend is a 
significant amount of work - why not profit from the work that we can 
share with the GTK port. The same code gets more testing exposure, and 
more smart people to look at it and fix it.

For each choice of library we may look at it:
* What's the required effort to keep the underlying library well 
maintained and who's going to do that with good response times?
* What performance or maintenance benefit do we get out of making a 
different choice? And for performance benefits, what are the hard 
numbers as opposed to hearsay?
* Are we ready to step up our efforts to test and maintain own code that 
we're not sharing with other ports?

Regards,

Dominik

-- 
Dominik Röttsches <dominik.rottsches at intel.com>



More information about the webkit-efl mailing list