[webkit-efl] Fwd: Re: Re: [E-devel] Deprecating WebKit EFL 1
gyuyoung.kim at samsung.com
Tue Oct 30 21:56:53 PDT 2012
I think this talk is too faster. There is no any Tizen product based on WK2 EFL yet. Beside some of other Samsung projects start | consider to use WK1 EFL internally as well as latest elementary library is still using WK1 as Cedric said. I would suggest to talk this issue after both stable WK2 EFL is released as commercial product and elementary uses WK2 EFL instead of WK1 without any problems. In addition, I don't think there was big effort to maintain WK1 port. They were just bug fixings or adjust WK2 features into WK1 so far.
BTW, as Cedric said, WebKit EFL contributors haven't been collaborated with EFL dev well. Although EFL contributors've been tried to use EFL libraries as much as possible, there might be some missing EFL usage even though they could use. I think we need to try to collaborate with EFL developers further and further.
------- Original Message -------
Sender : Cedric BAIL
Date : 2012-10-31 11:38 (GMT+09:00)
Title : Re: [webkit-efl] [E-devel] Deprecating WebKit EFL 1
On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri
> On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL wrote:
>> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez
>>>> There are lots of concerns from EFL developers (me included) on how
>>>> the development of WebKit-EFL is being done. The API of webkit2 even
>>>> not being fully supported by EFL, as contrary to webkit1. There's only
>>>> 1 developer that seemed to care and started to send patches to
>>>> elm-web, so webkit2 can be fully supported.
>>>> No surprise there was feedback asking for clarifications and why a
>>>> simpler api couldn't be used. Now you come and say WebKit1 is being
>>>> deprecated. -1000 here, until the day webkit2 gets fully supported in
>>>> EFL and you start to interact more with EFL devs.
>>> The proposed date for dropping WK1 EFL from upstream is 8 month away. I think this
>>> gives a reasonable amount of time for people currently relying on WK1 EFL to port their code to WK2 EFL.
>>> If anything, this should motivate people to make sure all the components work with WK2 EFL.
>> 8 months is clearly to short from now is clearly to short. 8 months
>> after WK2 EFL API is stabilized and "released" (I mean by that, that
>> any API/ABI break of it will be forbidden). Then you can consider
>> dropping WK1 EFL. Announcing that you will drop WK1 EFL when WK2 EFL
>> is not even stable, is not a proper move in my opinion.
>> Upstream EFL does use WK1 EFL in the 1.7.x branch, that will be used
>> by E17 release later this year. This means that all distribution that
>> do want to package EFL with a stable release for E17 will be depending
>> on WK1 EFL. You can stop development, only do bugfixes, but removing
>> it is clearly not a smart move here.
>>> About interaction with EFL developers, I don't think we have any problem answering questions related
>>> to WebKit EFL (via this mailing list or the IRC channel) or fix bugs filed upstream against WebKit EFL.
>> Yes, you have. I am aware of the move to WK2 EFL since less than 3
>> weeks. If some nice Samsung guy didn't try to help EFL upstream to
>> move away of WK1 EFL we wouldn't be even have any proper information
>> and code here. At this point, the WebKit EFL people need to get more
>> involved with EFL. It's not a matter of answering question, it's about
>> using the same tool and do that efficiently ! If we don't share
>> infromation more effectively, this kind of thread is going to repeat.
>> I strongly encourage every developer of WK EFL to join e-devel mailing
>> list and ping people there when there is important subject to bring in
>> (like new dependencies, feature request, ...). I am now subscribed to
>> this mailing list and will try to keep reading it, but that's not
>> enough. WK EFL team should get more engadged with EFL developer in
> 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.
webkit-efl mailing list
webkit-efl at lists.webkit.org
More information about the webkit-efl