30.09.2013, 17:39, "Dirk Schulze" <k...@webkit.org>: > On Sep 30, 2013, at 11:58 AM, Allan Sandfeld Jensen <k...@carewolf.com> wrote: > >> On Thursday 26 September 2013, Andreas Kling wrote: >>> On Sep 25, 2013, at 12:40 PM, Allan Sandfeld Jensen <k...@carewolf.com> >> wrote: >>>> On Saturday 14 September 2013, Andreas Kling wrote: >>>>> On Sep 14, 2013, at 11:24 AM, Allan Sandfeld Jensen <k...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
