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

[Maciej Stachowiak]

On Feb 8, 2013, at 2:33 PM, Darin Fisher <darin at chromium.org> wrote:

> 
> 
> 
> 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.

The example I was thinking of was adding support for an alternate JavaScript engine. If we'd stood firm on objections to that, it's unlikely Chromium would be in the tree. I'm glad we yielded on our objections there, even though there's some ongoing cost to the project from supporting two different JS engines. This is not to rehash old battles - I'm just suggesting that applying a little pragmatism may be appropriate.

> 
> 
> 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.

Thanks for acknowledging the benefits.

> 
> 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.

That's approximately what we're planning to do. We are upstreaming incrementally, starting with simple pieces, and documenting issues. The bug that sparked this thread was a relatively change to isMainThread(), plus a function rename, and we are no longer asking for the function rename. It will likely be a dozen line patch touching a single mac/ios-specific file.

We'd really like to fully upstream the simpler components like WTF (where the changes are all simple and targeted) even if we can't as easily do WebCore (where there may be more complex and controversial diffs).

Cheers,
Maciej




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130208/30cbd726/attachment.html>