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

[ryuan Choi]

Good point, I think.

But, I believe that webkit/efl use efl framework libraries `eventually`.

In my two cents,
webkit/efl should consider to use new library when someone (or team) make
the reasonable result.

Anyway, we can not move to libcurl, at least now. :)

Best Regards,
Ryuan Choi


2012/10/31 Dominik Röttsches <dominik.rottsches at intel.com>

> 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>
>
> ______________________________**_________________
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo/webkit-efl<http://lists.webkit.org/mailman/listinfo/webkit-efl>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-efl/attachments/20121101/a044e076/attachment-0001.html>