[webkit-dev] Changes in QtWebKit development

[Konstantin Tokarev]

30.09.2013, 17:39, "Dirk Schulze" <krit at webkit.org>:
> On Sep 30, 2013, at 11:58 AM, Allan Sandfeld Jensen <kde at carewolf.com> wrote:
>
>>  On Thursday 26 September 2013, Andreas Kling wrote:
>>>  On Sep 25, 2013, at 12:40 PM, Allan Sandfeld Jensen <kde at carewolf.com>
>>  wrote:
>>>>  On Saturday 14 September 2013, Andreas Kling wrote:
>>>>>  On Sep 14, 2013, at 11:24 AM, Allan Sandfeld Jensen <kde at carewolf.com>
>>>>  wrote:
>>>>>>  That said, in all likelihood the Qt port will not remain part of WebKit
>>>>>>  forever, ...
>>>>>  (This being the main reason.)
>>>>>
>>>>>  Since you already know you’re eventually going to leave, you could just
>>>>>  move to a branch sooner rather than later. It’s unreasonable to expect
>>>>>  WebKit to accommodate a port that has no forward-looking interest in the
>>>>>  project.
>>>>  We do have a  branch tagged and being prepared for 5.2. It was taken
>>>>  before the FTL merge and the following switch to require C++11 in all of
>>>>  the project. It will be very hard branch again after that point since we
>>>>  support 2-3 year old platforms by default, and the Webkit project want
>>>>  to move to using the latest and greatest compilers.
>>>  So you are saying that you'll never branch QtWebKit from WebKit trunk
>>>  again?
>>  I would love to, but I do not think it is going to happen. Quite honestly I
>>  wasn't sure I would be able to pull a new branch for 5.2 off, since older
>>  Linux (gcc 4.4), all windows builds and especially old OS X (10.6) were not
>>  building WebKit2 when I started. I got it working, but it the work to unroll
>>  unnecessary compiler features and library dependencies is just going to get
>>  harder from now on (if anyone want a patch to remove the C++11 requirement
>>  from WebKit2 late July, I have one).  If a new branch is made from WebKit
>>  trunk in the future would likely only be limited to specific platforms, and
>>  therefore not suited as a module shipped with Qt, but as an optional upgrade.
>>>  It’s commendable that you want to land your platform-agnostic patches
>>>  before withdrawing from the project, but assuming your last branch point
>>>  is already set, I don’t see why this necessitates keeping the Qt platform
>>>  code around.
>>  We all know what happens when a webkit port works on a branch. In theory it
>>  shouldn't be a problem, but as you know it didn't work for the N9 browser
>>  branch in Nokia, it didn't even work for the iOS branch at Apple!
>>
>>  So based on observations, I believe to be part of the project and able to
>>  commit upstream you must live upstream.
>
> I would not necessarily disagree with the problem of upstreaming work. But you said that most likely you wouldn't be able to branch WebKit anymore because of the compiler requirement.  At least for Qt. Do you have other interests in QtWebKit beside the integral part of Qt so that it makes sense for you to maintain the port further?
>
> Another question that is just partly related to WebKit but more curiosity.  Qt is deep integration into WebKit. We have (had?) a lot of Qt specific code in core WebCore to support QtXML and other things. Blink already stated that they would not accept such deep interventions in their platform. Is all that not important for you anymore? Can you operate with libxml2 and other libraries from now on? If that is the case, can't we limit the Qt specific code to just /platform/qt and remove all other Qt specific dependencies from WebCore?

For embedded targets libxml2 would be an additional dependency to build, and it would take additional space in device firmware. New XML parser from [1] would be better alternative if it was finished (and had decent performance).

[1] https://bugs.webkit.org/show_bug.cgi?id=64396

-- 
Regards,
Konstantin