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

Alexis Menard alexis at webkit.org
Tue Jan 22 03:32:02 PST 2013


On Tue, Jan 22, 2013 at 8:08 AM, Alexis Menard <alexis at webkit.org> wrote:
> On Tue, Jan 22, 2013 at 5:56 AM, Kenneth Rohde Christiansen
> <kenneth.christiansen at gmail.com> wrote:
>> The API is pretty separate and one of those things that AFAIU annoyed
>> Apple, especially when it is based on non WK C API. Moving it and the
>> unit tests seems like the right thing to do, as it is a separate layer
>> on top of WK2. As part of that work we can minimize the amount of code
>> not using public "C" API.
>>
>> Yeah, it will not fix all our problems. That is not what we indent
>> with this move.
>>
>> Also moving everything now is not what "the community" wants us to do.
>> Jocelyn already suggested that, which was shot down as a bad idea by
>> Sam.
>>
>
> The proposal of Jocelyn was not the one people are talking here.
> Jocelyn wanted to add more abstraction to be able to implement outside
> WK2 some stuff (like the scrolling and so on).
>
> From what I understand people think of this one :
>
> cp -r Source/WebKit2 Source/WebKit2NonApple/
> (git revert the mess that with the frameloader?)
> git add Source/WebKit2NonApple/
>
>> Major changed might just cause more harm, minor incremental ones are
>> less disruptive and hopefully when well considered, will bring us
>> forward.
>
> Sure, but that is us playing the game, where Apple clearly does not.
>
>>
>> I still support this move
>
> I still support *a* move.

Ok after a chat with kenneth I support the move. It's a first step needed.

>
>> Kenneth
>>
>> On Tue, Jan 22, 2013 at 9:33 AM, Pozdnyakov, Mikhail
>> <mikhail.pozdnyakov at intel.com> wrote:
>>> 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.
>>>
>>> _______________________________________________
>>> webkit-efl mailing list
>>> webkit-efl at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-efl
>>
>>
>>
>> --
>> Kenneth Rohde Christiansen
>> Senior Engineer, WebKit, Qt, EFL
>> Phone  +45 4294 9458 / E-mail kenneth at webkit.org
>>
>> ﹆﹆﹆
>> _______________________________________________
>> webkit-efl mailing list
>> webkit-efl at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-efl
>
>
>
> --
> Software Engineer @
> Intel Open Source Technology Center



-- 
Software Engineer @
Intel Open Source Technology Center


More information about the webkit-efl mailing list