[webkit-efl] Moving the EFL WebKit2 public APIs to outside WebKit2 directory

[Pozdnyakov, Mikhail]

Hi, 

Right, API part is not that big part and moving it out alone would not give much benefits.
Is our main problem in upstreaming patches within this particular area?

I think the real problems that we have (for instance if some APIs are stopped being supported on generic WK2 level) are not gonna be solved
with this minor movement.

Furthermore reviewing our patches by Apple guys has advantages as they have better understanding of WK2 architecture and plans
for its modification (which we are not aware).

BR,
Mikhail

________________________________________
From: webkit-efl-bounces at lists.webkit.org [webkit-efl-bounces at lists.webkit.org] on behalf of Vyacheslav Ostapenko [ostap73 at gmail.com]
Sent: Monday, January 21, 2013 7:52 PM
To: webkit-efl at lists.webkit.org
Subject: Re: [webkit-efl] Moving the EFL WebKit2 public APIs to outside WebKit2 directory

Hi All,

  Why only API part? I think everything that is not used by apple should go outside of Source/WebKit2.
  We should create something like Source/WebKit2Ports, shadow the structure of WebKit2 there and move all the code that is not compiled by Apple, like APIs, CoordinatedGraphics, shared memory and process mangement and etc.
  Of course it will not solve the problem of Apple breaking Qt, EFL and GTK ports, but at least it will allow easier fixes of port specific issues.

Slava

On Mon, Jan 21, 2013 at 11:48 AM, Thiago Marcos P. Santos <tmpsantos at gmail.com<mailto:tmpsantos at gmail.com>> wrote:
Hi Ewkitters,

The recent changes on the reviewing policy for the code located inside
Source/WebKit2 directory has been affecting the speed of how the EFL
port moves forward. The additional burden for the WebKit2 Owners to
review code from all the the ports has obviously its implications. We
have red bots for days because of pending patches.

We can minimize this overhead and let the WebKit2 Owners focus on
reviewing the core components by moving the EFL WK2 public API and
unit tests to outside the Source/WebKit2 directory. The best place I
see would be Source/Platform/efl, which will be consistent with how
the Chromium API files are placed inside the WebKit tree.

This is the directory structure I'm proposing (using Chromium as role model):

Source/WebKit2/UIProcess/API/efl/ (public headers) -> Source/Platform/efl/public
Source/WebKit2/UIProcess/API/efl/ (the rest) -> Source/Platform/efl/src

Note that we are initially moving _only_ the API and utests. Other
things, which are probably 5% of what is left of EFL code, can be
moved later if needed.

Comments anyone? I'm volunteering myself for the task.

Cheers,
_______________________________________________
webkit-efl mailing list
webkit-efl at lists.webkit.org<mailto:webkit-efl at lists.webkit.org>
http://lists.webkit.org/mailman/listinfo/webkit-efl

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.