[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