[Webkit-unassigned] [Bug 68460] Add WebCore platform interfaces needed by updated MediaStream and PeerConnection design

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Sep 22 17:29:47 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=68460





--- Comment #18 from Adam Barth <abarth at webkit.org>  2011-09-22 17:29:47 PST ---
> Isn't it preferable to keep that kind of code in WebCore for consistent behavior between ports and to avoid having to change every implementation of the platform interface when the PeerConnection APi is updated?

There's definitely a trade-off between putting things in WebCore versus in libraries.  It's not always clear where to draw the line.  For example, if HTTP were invented today, it's very likely Hixie would have written the XMLHttpRequest as imperatively manipulating HTTP protocol elements.  We could, of course, suck the implementation of the whole HTTP protocol into WebCore, as we have done with WebSockets, but there's a trade-off.

In many ways, we're still feeling our way though these kinds of decisions.  We can certainly discuss this topic more on webkit-dev if you'd like to get input from the broader community (who might not all be CCed on this bug).

My perspective is that we'll need to modularize WebCore more as time goes on, otherwise WebCore will grow to be unbounded in complexity and won't be lean.  Core functionality, like layout and rendering should stay, of course, but over time we should move more into separate libraries with clear dependencies.  Whether those libraries are in svn.webkit.org or elsewhere is a separate issue.

> Please have a look at how PeerConnection uses PeerHandler in https://bugs.webkit.org/attachment.cgi?id=108421&action=review , as compared to how it uses MediaStreamClient at the moment.

I really appreciate that you've posted the whole patch so we can use that as a reference for discussion.  There are a lot of details in how PeerConnection uses PeerHandler that I think are less than ideal.  For example, I'd rather WebCore be ignorant of concepts like STUN.  I suspect if you asked the vast majority of WebKit developers what STUN was, they'd have no idea.  That means code that talks about STUN is mysterious and won't be well maintained.

I guess I don't understand what you find objectionable about the layering diagram in Comment #16.  It gives folks the option of using a high-level library or a lower-level library.  The issue of whether to spin the PeerHandler-based implementation out into a separate library is something we can worry about in the future.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list