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 > ------------------------------------------------------------------------------ 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
