WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
99435
MediaStream API: Add the chromium API for RTCDataChannel
https://bugs.webkit.org/show_bug.cgi?id=99435
Summary
MediaStream API: Add the chromium API for RTCDataChannel
Tommy Widenflycht
Reported
2012-10-16 01:44:05 PDT
Add the chromium API for RTCDataChannel, as well as DRT mock changes and tests.
Attachments
Patch
(32.12 KB, patch)
2012-10-16 02:30 PDT
,
Tommy Widenflycht
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Tommy Widenflycht
Comment 1
2012-10-16 02:30:51 PDT
Created
attachment 168898
[details]
Patch
Rik Cabanier
Comment 2
2012-10-16 08:58:43 PDT
Please wait for approval from
abarth@webkit.org
,
dglazkov@chromium.org
,
fishd@chromium.org
,
jamesr@chromium.org
or
tkent@chromium.org
before submitting, as this patch contains changes to the Chromium public API. See also
https://trac.webkit.org/wiki/ChromiumWebKitAPI
.
Adam Barth
Comment 3
2012-10-16 12:15:16 PDT
Comment on
attachment 168898
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=168898&action=review
> Source/Platform/chromium/public/WebRTCPeerConnectionHandler.h:71 > + // RTCDataChannel > + virtual bool openDataChannel(const WebRTCDataChannel&) { return false; } > + virtual bool sendStringData(const WebRTCDataChannel&, const WebString&) { return false; } > + virtual bool sendRawData(const WebRTCDataChannel&, const char*, size_t) { return false; } > + virtual void closeDataChannel(const WebRTCDataChannel&) { }
The relationship between the PeerConnectionHandler and the DataChannel are slightly strange. The data channel seems to represent the WebKit side of the channel and you're using PeerConnectionHandler as the embedder endpoint. I would have expected the DataChannel to have more a of a send/didReceive sort of API, but this approach seems ok too.
WebKit Review Bot
Comment 4
2012-10-16 12:47:45 PDT
Comment on
attachment 168898
[details]
Patch Rejecting
attachment 168898
[details]
from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: Auto-merging Source/WebCore/ChangeLog CONFLICT (content): Merge conflict in Source/WebCore/ChangeLog Failed to merge in the changes. Patch failed at 0001 Rename some AudioNodes When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". rebase refs/remotes/origin/master: command returned error: 1 Died at Tools/Scripts/update-webkit line 164. Full output:
http://queues.webkit.org/results/14391275
WebKit Review Bot
Comment 5
2012-10-16 13:41:39 PDT
Comment on
attachment 168898
[details]
Patch Clearing flags on attachment: 168898 Committed
r131494
: <
http://trac.webkit.org/changeset/131494
>
WebKit Review Bot
Comment 6
2012-10-16 13:41:45 PDT
All reviewed patches have been landed. Closing bug.
Tommy Widenflycht
Comment 7
2012-10-17 01:58:52 PDT
(In reply to
comment #3
)
> (From update of
attachment 168898
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=168898&action=review
> > > Source/Platform/chromium/public/WebRTCPeerConnectionHandler.h:71 > > + // RTCDataChannel > > + virtual bool openDataChannel(const WebRTCDataChannel&) { return false; } > > + virtual bool sendStringData(const WebRTCDataChannel&, const WebString&) { return false; } > > + virtual bool sendRawData(const WebRTCDataChannel&, const char*, size_t) { return false; } > > + virtual void closeDataChannel(const WebRTCDataChannel&) { } > > The relationship between the PeerConnectionHandler and the DataChannel are slightly strange. The data channel seems to represent the WebKit side of the channel and you're using PeerConnectionHandler as the embedder endpoint. I would have expected the DataChannel to have more a of a send/didReceive sort of API, but this approach seems ok too.
It's a very good comment, I implemented it like this for two reasons: 1) Data channels are not stand-alone entities like websockets are, they are "only" a view into part of the data stream between two PeerConnections. Hence it makes some sense of extending the PeerConnection handler interface. 2) The current descriptor pattern that we are using doesn't really work for communication from JS to the UA, but the other way is fine.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug