On Wed, Oct 31, 2012 at 5:22 PM, ryuan Choi <ryuan.c...@gmail.com> wrote: > 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.
http://curl.haxx.se/docs/http-cookies.html I think that if you think that libcurl has missing features, maybe you should ask if they exist first in the curl mailing list or its IRC chan. Vincent ------------------------------------------------------------------------------ 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
