2012/11/1 Gustavo Sverzut Barbieri <barbi...@profusion.mobi>

> On Wed, Oct 31, 2012 at 12:57 PM, Thiago Marcos P. Santos
> <tmpsan...@gmail.com> wrote:
> > On Wed, Oct 31, 2012 at 2:07 PM, Vincent Torri <vincent.to...@gmail.com>
> wrote:
> >> On Wed, Oct 31, 2012 at 1:03 PM, Gustavo Lima Chaves
> >> <gl...@profusion.mobi> wrote:
> >>> * Cedric BAIL <cedric.b...@free.fr> [2012-10-31 11:38:52 +0900]:
> >>>
> >>>> On Wed, Oct 31, 2012 at 11:23 AM, Gustavo Sverzut Barbieri
> >>>> <barbi...@profusion.mobi> wrote:
> >>>> > On Tue, Oct 30, 2012 at 11:53 PM, Cedric BAIL <cedric.b...@free.fr>
> wrote:
> >>>> >> Hello,
> >>>> >>
> >>>> >> On Wed, Oct 31, 2012 at 1:10 AM, Christophe Dumez
> >>>> >> <christophe.du...@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.
> >>
> >> what about using enesim instead of cairo ? The rendering of esvg is
> >> faster than with librsvg, and is much more powerful, and it is not
> >> optimized, so plenty of room for improvements
> >>
> >
> > Dominik has a good point about the same subject:
> > http://lists.webkit.org/pipermail/webkit-efl/2012-October/000417.html
>
> The problem is that libsoup depends on shitloads of other libraries
> just to provide HTTP.
>

> If curl is not enough, pretty sure can turn into a task to write a
> proper implementation that fulfill WebKit needs and that is integrated
> into EFL.
>
> +1 in the viewpoint that libcurl is way to go.
But it may not be easy work.

When we decide to use libsoup as default network backend, libcurl backend
has many missing features such as cookie, cache, and so on.
IIRC, they are still missing features.

Anyway, I will raise this item when we discuss future plan of WebKit/tizen.


As for the graphics, I don't mind Cairo or Skia. If someone (Jorge)
> provides a GraphicsContext using his library would be nice as well.
>
>
If we have good alternatives, could you let me know?
Our graphics team may check the performance for next plan.


> BR,
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --------------------------------------
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to