yeah we need colaboration. i think this is a good start. Daniel Juyung Seo (SeoZ) On Oct 24, 2012 6:38 AM, "Gustavo Sverzut Barbieri" <barbi...@profusion.mobi> wrote:
> 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 > ------------------------------------------------------------------------------ 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
