[webkit-efl] [E-devel] Deprecating WebKit EFL 1

[Gustavo Lima Chaves]

* Cedric BAIL <cedric.bail at free.fr> [2012-10-31 11:38:52 +0900]:

> 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:
> >> Hello,
> >>
> >> 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
> >> general.
> >
> > 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.

> -- 
> Cedric BAIL
> _______________________________________________
> webkit-efl mailing list
> webkit-efl at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-efl

-- 
Gustavo Lima Chaves
Computer Engineer @ ProFUSION Embedded Systems