I rebased patch including elm_need_web and _elm_unneed_web. Could you let me know what should I do to land this patch?
Best Regards, Ryuan Choi 2012/10/24 ryuan Choi <ryuan.c...@gmail.com> > > > 2012/10/24 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> > >> On Mon, Oct 22, 2012 at 10:15 PM, ryuan Choi <ryuan.c...@gmail.com> >> wrote: >> > In the view point of basic behavior, right, they should be almost same. >> > >> > Now, There are three reasons not to keep the same structure >> > >> > 1. WebKit2/efl ignores or choose different(better?) API names from >> > WebKit1/Efl. >> > It's sad but true. >> > >> > For example, >> > - reload_bypass_cache instead of reload_full ( >> > https://bugs.webkit.org/show_bug.cgi?id=89413#c4 ) >> >> I dislike this fscking long name, but anyway... if you change in one, >> change everywhere. > > > Sure, if I can. > Now, I think that I must sync with elm-web and eve when I change these API > of ewebkit. > > Do I need to check any more components? > > > > >> > - WebKit2/Efl decides to use `url` instead of `uri` ( >> > http://lists.webkit.org/pipermail/webkit-efl/2012-October/000312.html ) >> >> this is for webkit2... how about webkit1? Why webkit2 did not follow >> webkit1? >> >> > As you mentioned below, > I think that WebKit/Efl developers does not care much about EFL side. > > It's the one of reasons which I decide to dive in EFL community. > > Now, many decision of WebKit/Efl are discussed in > webkit-...@lists.webkit.org ( > http://lists.webkit.org/mailman/listinfo/webkit-efl). > I hope that more EFL peoples get interested in WebKit/Efl because most > developers of WebKit/Efl are newbies in EFL side. > > > - WebKit2/Efl does not expose methods of structure. >> >> it should, otherwise how do you plan to extend it? >> >> Sorry, It's my wrong comment. > I mean that WebKit2/Efl just expose the methods instead of whole structure. > > please ignore this. > > >> > If allowed, I want to reduce these by refactoring WebKit1/Efl API. >> >> I'm fine with that, but they use the same base, with the smart class >> being common in some basic points such as setting location, >> navigation, etc. >> >> Sorry, I can not understand fully. > I want to reduce the differences. > I hope that Ewk_View_Smart_Class and Ewk_View_Smart_Data are eventually > same in both ewebkit and ewebkit2. > > >> >> >> > 2. Some APIs depends on architecture. >> > Because of process model, WebKit2/Efl has new data type, ewk_context to >> > manage web process, and different setting APIs. >> > WebKit1 provides setting for each ewk_view, but WebKit2 provides it for >> > each ewk_context. >> >> what is the ewk_context? Is it shared by multiple views? is it bound >> to a single ewk_view? >> >> Yes, it can be shared by multiple views. > ewk_context and ewk_view have one to many relations. > > And two ewk_context means two web processes. > Application may decide process model. > > > >> >> >> > Indeed, some of APIs such as ewk_frame_script_execute should be changed >> to >> > asynchronous model in WebKit2 >> >> it should, yes. Also the webkit itself should avoid these synchronous >> API as we always complained. Same for alert()/confirm() handling. >> >> I hope also. > But now it makes a gap between ewebkit and ewebkit2. > > I hope that we solve all issues step by step on more collaboration with > EFL. > > >> > 3. WebKit2/Efl can not have some features of WebKit1/Efl. >> > WebKit2 is common ports and WebKit2/Efl just provides the wrapper of >> > WebKit2 C API. >> > On the other hand, WebKit1/Efl uses more functionality of WebCore. >> > >> > For example, WebKit1 has a lot of ewk_frame APIs, ewk_view_tiled for >> better >> > scrolling. >> >> so what? I don't get it. If it's use more WebCore, it doesn't matter >> as it's hidden. If you can't manipulate or access frames, just don't >> return them. There is no way the user creates ewk_frame from outside, >> they all come from ewk_view. >> >> as for ewk_view_tiled, you can keep that without problems. It's all >> internal anyway, you can instantiate the single or tiled backing >> store. It's independent, as it would be webkit2. >> > > I just listed examples of differences between ewebkit and ewebkit2. > To reduce differences of it, we may need to fix them like you mentioned. > > > >> How is doing this architecture and management of WebKit2/EFL? It seems >> that these people don't care much about the EFL part of the port, as >> we do not see them talking in our lists and so on... as the port is a >> binding of WebKit with EFL, I'd expect more collaboration with the >> EFL. >> >> > I absolutely agree and we must do. > > I already mentioned, > WebKit/Efl itself has had many discussion in webkit/efl mailing list. > I hope that I can see the many EFL voices when webkit/fl decides something. > > In addition, I will encourage my colleagues to dive in EFL community. > > Best Regards, > Ryuan Choi > > -- >> 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 >> > >
elm_web_for_webkit2_share_codes.patch
Description: Binary data
------------------------------------------------------------------------------ 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
