[webkit-dev] Changes in QtWebKit development

[Arunprasad Rajkumar]

"New XML parser" was removed from the tree [1].

[1] https://lists.webkit.org/pipermail/webkit-dev/2012-August/022103.html

http://trac.webkit.org/changeset/140399


On 30 September 2013 19:18, Konstantin Tokarev <annulen at yandex.ru> wrote:

>
>
> 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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130930/b551e1eb/attachment.html>