[webkit-efl] [E-devel] Deprecating WebKit EFL 1
cedric.bail at free.fr
Tue Oct 30 19:38:52 PDT 2012
On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri
<barbieri at profusion.mobi> wrote:
> On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL <cedric.bail at free.fr> wrote:
>> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez
>> <christophe.dumez at intel.com> wrote:
>>>> 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.
More information about the webkit-efl