[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
Fri Sep 23 08:25:22 PDT 2011


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





--- Comment #20 from Adam Bergkvist <adam.bergkvist at ericsson.com>  2011-09-23 08:25:21 PST ---
(In reply to comment #18)
> 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.

Yes, it's easier to talk about PeerHandler together with PeerConnection rather than out of context (since PeerConnection isn't included in the patch for this bug). The word "STUN" is used in the configuration string argument to the PeerConnection constructor and therefore a part of the configuration object. For example

var pc = new PeerConnection("STUN stun.example.org:3478", callback);

We can remove the parsing and simply pass the configuration string to the platform. Would that be acceptable?

The logic we want to add to PeerConnection is only related to the JavaScript API. For example

pc.addStream(stream1);
pc.addStream(stream2);

in the same event-loop iteration should, according to the specification, be treated as if you're adding a list of streams at once. The streams should be handled together and only result in one signaling message. That's why PeerHandler has addPendingStreams() rather than a direct counterpart to PeerConnection's addStream().

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

The layering diagram looks fine to me. I see the logic that we're adding to PeerConnection as part of the "Bindings" box and PeerHandler is the API towards the "P2P" box. The "P2P" box can then be implemented with either a high-level or a lower-level library.

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