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. > - 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? > - WebKit2/Efl does not expose methods of structure. it should, otherwise how do you plan to extend it? > 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. > 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? > 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. > 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. 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. -- 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
