[webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Darin Fisher]

On Fri, Feb 8, 2013 at 2:05 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Feb 8, 2013, at 1:41 PM, Adam Barth <abarth at webkit.org> wrote:
>
> > Context: https://bugs.webkit.org/show_bug.cgi?id=109071
> >
> > Adam Barth said:
> >> It's not clear to me that running WebCore on multiple interlocked
> threads is a good idea.  That
> >> seems like a pretty major change to WebCore's architecture.  Is that
> something that's up for
> >> discussion?
> >
> > Darin Adler said:
> >> I agree that it’s not something I’d do if I was starting a project now.
> >>
> >> In the iOS context, it’s fantastic for discussion as a possibly
> multi-year major architecture
> >> change, but if we take a hard line on this, then we won’t have the iOS
> port in the tree for
> >> years, and I think it would be good if we do. iOS WebKit has worked
> this way for the entire
> >> history of iPhone, so it’s not a change that can be made easily.
> >
> > Darin Adler also said:
> >> I think where you and I may differ is on whether a good solution to the
> problem would be
> >> valuable to the WebKit project. Is there some way I convince you of the
> value of fitting
> >> an important existing port of WebKit into our tree in as clean as
> possible a way?
> >
> > I don't really know how to respond to this thread.  I feel like I'm
> > being offered the following choice:
> >
> > 1) Give up the ability to have technical input to how WebCore works
> > and simply accept all the design choices made in the iOS fork, whether
> > they be good choices or bad.
> >
> > 2) Keep the iOS port in an Apple-internal fork for a number of years.
> >
> > I feel like I'm being asked to make this choice in the context of a
> > growing trend of unilateral action by Apple in this project.  Given
> > that trend, I don't see how I can choose option (1).
> >
> > As much as I would like the iOS port merged into trunk, I'm not
> > willing to give up having a technical say in the project.  Therefore,
> > reluctantly, I'm forced to choose option (2).
>
> If we'd taken an equally hard line when Google wanted to merge the
> Chromium port to trunk, with a number of design choices in place that we
> didn't agree with but which were hard to change, it probably still wouldn't
> be in the tree to this day. I don't think that would have been a good thing
> for the WebKit project.
>

I think this is a bit different.

For the Chromium port, we started out with the assumption that we couldn't
easily change much about the architecture of WebCore.  Instead, we tried to
make Chromium match the set of constraints imposed on WebCore by WebKit,
CFNetwork, CoreGraphics and more recently CoreAnimation.

This led to things like hiding the details of the out-of-process network
stack behind ResourceHandle.  We did so because we assumed that it would
make our port less of a burden to others.



>
> I am curious how others feel about the value of merging the iOS port back
> to trunk as soon as possible, vs. the need to fix all of the past design
> decisions in this port that may be disputed.
>

I think it is valuable to upstream the iOS port.  I'm sad that it has not
happened sooner.  Many times, the architecture of the iOS port has been
used as justification by Apple engineers for why WebCore should work a
certain way.  It is often not obvious from the open source code that such
constraints exist.  Having the code in the open would seem to help with
such issues.

I would recommend minimizing the re-architecture of WebCore as you are in
the early stages of upstreaming.  It seems like you already have a working
port that you could simply upstream.  You could then work with others in
the community to introduce new concepts to WebCore with the full disclosure
of code as an aide to the process.  Another option might be to open source
the entire thing as a branch somewhere.

After the initial upstreaming or sharing of code is complete, you could
then catalog all of the warts.  The fact that isMainThread returns true
when called on more than one thread would be one such wart.  I can imagine
a meta bug tracking all of these warts.  This would make it a lot easier
for others to understand the overall change in direction needed for WebKit
to properly support the iOS port.

Hope this helps!
-Darin



>
> Regards,
> Maciej
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130208/792cb332/attachment.html>